SQLite store - V1 schema implementation.

Every public defn in this file is dispatched dynamically by
`vis-sdk.core/defdelegate` via `ns-resolve`; clj-kondo never sees
the call sites. The ns-level config above silences
`:unused-public-var` for the whole file. The actual call surface
is verified through the storage facade tests.

Tables (V1__schema.sql):
  session_soul, session_state,
  session_turn_soul, session_turn_state,
  session_turn_iteration, llm_routing_event,
  extension_aggregate,
  log

Connection lifecycle:
  (db-open! db-spec)   -> {:datasource ds :path ...}
  (db-close! store)    -> idempotent dispose

Flyway-backed schema migration runner.

Lives in the SQLite extension because:

  1. The dialect-specific Flyway driver (`flyway-database-nc-sqlite`)
     is required to recognize `jdbc:sqlite:` URLs - already
     declared in this extension's deps.edn.
  2. Flyway is the only backend-side concern using
     `flyway-core`; making it a per-backend dep keeps the root
     package free of the migration toolchain.
  3. The previous arrangement shipped a generic `migrate!` from
     `com.blockether.vis.sdk`, but it had exactly one caller
     - this extension. Other backends will ship their own
     migration entry point in their own jar.

Public API:

  `(migrate! datasource locations)` - apply every Flyway
  migration found at the given classpath `locations` to the
  supplied `DataSource`. Returns the datasource for thread-style
  chaining.

`:baseline-on-migrate true` so existing databases without a
`flyway_schema_history` table get one on first run. `:mixed true`
so SQL files with mixed transactional + DDL statements work under
SQLite.

GraalVM native-image note: Flyway discovers migrations by LISTING the
classpath location directory, which native-image does not support (it can
`getResource` a specific file but not enumerate a dir). So `build.clj` writes
an `_index.edn` of filenames next to each migration dir, and here we feed
Flyway an explicit `ResourceProvider` built from those exact paths. On the
JVM (no index) we fall back to Flyway's normal location scanning.

Lightweight backend registrar for the SQLite persistence extension.

Manifest discovery loads this namespace on every Vis startup. The
heavyweight `com.blockether.vis.ext.persistance-sqlite.core` namespace
(HikariCP, sqlite-jdbc, charred, honey.sql, next.jdbc, nippy, ... -
~480 ms of class loading on a cold JVM) is NOT required here.

`:ext/persistance` registers the backend with `:persistance/ns` pointing
at the heavy `core` ns. The persistance facade resolves backend vars
with `requiring-resolve` (see
`com.blockether.vis.internal.persistance/resolve-impl`), so the heavy
ns auto-loads on the first real DB op. Commands that never touch the
DB (`vis providers list`, `vis --help`, `vis doctor` for
non-DB-touching extensions, ...) skip the load entirely.

The contract that flips with this split:
- `(require 'com.blockether.vis.ext.persistance-sqlite.core)` does
  NOT register the extension on its own anymore - it just defines the
  fns. Tests that only need the fns can keep requiring core directly.
  Tests / runtime that need the extension registered should require
  this `registrar` ns OR rely on classpath manifest discovery (which
  loads this ns).

Runtime semantics are untouched: when the persistance
facade actually dispatches a backend call, the heavy ns loads, and
every fn is found exactly as before. The split only changes WHEN the
heavy ns is loaded, never WHAT it does.