Bounded Datahike calls: every read runs on ONE bounded executor under a
deadline, with one reopen-and-retry on a non-timeout failure.

Why not `hive-weave.retry/with-recovery`: up to hive-weave 0.4.2 it calls
`safe-future-call` without a :pool, so every read is a `clojure.core/future`
on the unbounded send-off pool (measured: 114 send-off threads, the largest
CPU bucket in the JVM). `safe-future-call` itself takes :pool since 0.4.x,
which is all this namespace needs. Once a hive-weave release whose
`with-recovery` forwards :pool is pinned in deps.edn, `read-with-retry` can
collapse onto it with the same options.

The executor is a port: the store is built with one (`:read-pool` on
`create-store`) and tests hand it a recording one.

Copy a Datahike store into a NEW store with `:keep-history? false`.

Datahike validates the connect-time config against the stored one, so
`:keep-history?` cannot be changed in place — a store created with history
refuses to open under a config that disables it. The only route is a copy.

Contract:
  (plan source-cfg target-cfg)  => the migration plan, no I/O beyond a read
  (migrate! opts)               => Result<report>

`migrate!` NEVER writes to, deletes, or reconfigures the source. It refuses
to run without `:i-mean-it true`, and refuses a target that already exists.

Datahike implementation of hive-spi.kg.protocol/IKGStore + IPersistentKGStore
+ ITemporalKGStore. Config (db-path/backend/store-id/writer) and the core-norms
classpath resource are injected by the host — the store resolves no env/config
of its own and carries no hive-mcp dependency.