Ktor plugin lifecycle: closes user-supplied pools, requires HikariCP to shut down, eager DI resolution can abort startup

[zantvoort]

Three lifecycle defects in the Ktor plugin:

1. closeDataSourceIfManaged (storm-ktor/src/main/kotlin/st/orm/ktor/StormDataSource.kt:74-78) closes any HikariDataSource, including one the user passed in, contradicting docs/ktor-integration.md:137 ("if it is a HikariDataSource that the plugin created"). Ownership is never tracked; capture ownsDataSource = pluginConfig.dataSource == null at creation (Storm.kt:117) and close only what the plugin owns.
2. The same method needs the HikariDataSource class to resolve while HikariCP is provided scope, so on a runtime without it (Agroal, plain DriverManager, or storm-ktor-test's own classpath) shutdown throws NoClassDefFoundError, swallowed at DEBUG by Ktor's safeRaiseEvent. Guard the type check behind a classpath probe.
3. The eager DI resolution loop (Storm.kt:217-225) resolves every provided key on ApplicationStarted to suppress shutdown warnings, but ApplicationStarted is raised through plain Events.raise, so any resolution failure (an ambiguous covariant repository key, for example) aborts application start for a key nothing in the app ever needed. Catch per key and log at DEBUG, or resolve only keys the container holds unfinished.