SqlCapture cannot capture from Kotlin coroutines, and Kotlin lacks a blocking sqlLog

[zantvoort]

SqlInterceptorManager.LOCAL_OPERATORS is a plain ThreadLocal (storm-core/src/main/java/st/orm/core/template/impl/SqlInterceptorManager.java:214). The coroutine-aware plumbing exists (storm-kotlin/src/main/kotlin/st/orm/template/impl/SqlLogRecording.kt:63 binds via asContextElement), but SqlCapture does not use it, so nothing is captured across a suspension or dispatcher hop.

Compounding it, the entry point is named run(Runnable): in Kotlin, capture.run { someSuspendCall() } resolves to kotlin.run, compiles fine, and captures nothing. The Ktor docs example (docs/ktor-integration.md:796-811) is exactly this shape, and storm-ktor-test hands out a SqlCapture that nothing installs (its own test asserts only non-null). The javadoc also claims propagation to "child threads" in four places (:286-291, :300-306, :317-323, :413-419), which is false for a non-inheritable ThreadLocal.

Related gap in the same area: sqlLog { } is suspend-only (SqlLogs.kt:105) while transactions ship as a transaction/transactionBlocking pair, so blocking Kotlin code (Spring MVC being the common case) has no way to open a SQL-log scope from Kotlin at all.

Fix: coroutine-safe capture (context-element binding like SqlLogRecording), a Kotlin-friendly capture entry point that cannot be shadowed by kotlin.run, a sqlLogBlocking counterpart, corrected javadoc, and a Ktor example that actually works.