PLA-51: give storage its own owner instead of the Sessions registry

[hristo2612]

Selected area

packages/jinn/src/sessions/registry.ts — the Sessions registry, which also owned the
process-wide SQLite bootstrap for every other module in the gateway.

Evidence of over-engineering / blended concerns (measured at base 23df25ed)

registry.ts was 3,985 lines and held three unrelated responsibilities:

1. Session/message CRUD — its actual job.
2. The process-wide storage bootstrap — the db singleton, initDb(), disk
   preflight, pre-migration backup/prune, DB-version sidecar, and the SQLite
   busy-retry helpers.
3. Other modules' schema migrations — the single initialize immediate
   transaction created and migrated Sessions, Messages, messages_fts,
   queue_items, callback deliveries, Files and chat pins, and called
   migrateWorkItemsSchema (Todos) and migrateActivitySchema (Activity).

Consequences of the blend:

• 102 files referenced initDb. Every non-session module — work-items (×9),
  activity (×2), gateway, cron, cli, knowledge — reached its database handle by
  importing from the Sessions module. Storage ownership was expressed as a
  dependency on an unrelated domain.
• Four modules imported pure string sanitizers from the registry.
  knowledge/store.ts, mcp/knowledge-tools.ts, gateway/files.ts and
  gateway/api.ts pulled stripControlChars / hasControlBytes out of a
  3,985-line session-CRUD file.
• Todo-primitive doctrine prose lived in a comment block inside the Sessions
  registry, documenting a domain the file does not own.
• The codebase already had the right convention in two places and was not
  following it in the third: work-items/migrate.ts and activity/migrate.ts
  already exist, and workflows/repository-migrations.ts already exports
  openWorkflowDatabase() owning its own store.

Fixed constraint budget

Frozen in PLAN.md before implementation:

Field	Budget
netLineDelta	≤ 0
maxFilesTouched	110
maxNewFiles	3
maxFileLines	7584

Measured budget output

Command run verbatim from PLAN.md at the pushed head:

netLineDelta=-4
filesTouched=109
newFiles=3
maxTouchedFileLines=7583

All four inside budget.

What was deleted or clarified

Three new files, each owning one concern:

File	Lines	Owns
packages/jinn/src/shared/db.ts	220	The storage bootstrap. Declares the db singleton and initDb(), plus disk preflight, pre-migration backup/prune, version sidecar and the busy-retry helpers. A composition root: it sequences each owner's migration but contains no DDL and no domain logic.
packages/jinn/src/sessions/migrate.ts	933	Sessions-owned DDL and migrations, moved verbatim — the CREATE_* constants and migrateMessagesSchema / migrateSessionsSchema / migrateFtsSchema / migrateQueueItemsSchema / migrateCallbackDeliveriesSchema.
packages/jinn/src/shared/sanitize.ts	22	stripControlChars and hasControlBytes, moved verbatim.

Removed from registry.ts: 1,174 lines deleted, 4 added — 3,985 → 2,815 lines.

• initDb is now declared in exactly one place (shared/db.ts:136). registry.ts
  imports it like every other module (registry.ts:5) and does not re-export it,
  so nothing reaches storage through Sessions any more.
• migrateWorkItemsSchema and migrateActivitySchema no longer appear in
  registry.ts; shared/db.ts sequences them from their owning modules'
  migrate.ts.
• The Todo-primitive doctrine prose block is gone.
• The ~100 initDb importers were re-pointed mechanically — same exported name,
  one import line changed per file.

Import-cycle hazard, resolved without a cycle. migrateCallbackDeliveriesSchema
called runImmediateMigrationWithRetry, which would have created a
shared/db.ts ↔ sessions/migrate.ts cycle. The transaction runner is passed in
as a plain function parameter from the composition root instead. Verified: none of
sessions/migrate.ts, work-items/migrate.ts, activity/migrate.ts imports
shared/db.js or sessions/registry.js.

Deliberately not done (the constraint budget forbade it): no registration or
plugin framework, no registerMigration() indirection, no renamed public functions,
no new dependencies or config options. shared/db.ts calls the three owners directly.

Behaviour: pure code motion plus import re-pointing. No SQL text changed, no
migration-order changed — the initialize transaction runs the same steps in the
same sequence inside one runImmediateMigrationWithRetry call.

Acceptance greps at the pushed head

registry importers of initDb/sanitizers ....... NONE
registry declares or re-exports initDb ........ NONE  (declared only in shared/db.ts:136)
migrateWorkItemsSchema/migrateActivitySchema .. NONE  (in registry.ts)
Todo-doctrine prose in registry.ts ............ NONE
migrate.ts files importing db/registry ........ NONE  (no module-scope cycle)

Test results

Turbo replays cached logs across worktrees, so every gate below was run with the
cache bypassed (Cached: 0 cached) — these are real executions at the pushed head,
after the final commit.

pnpm typecheck --force

 Tasks:    2 successful, 2 total
Cached:    0 cached, 2 total
  Time:    4.433s

pnpm test --force

jinn-cli:test:  Test Files  309 passed (309)
jinn-cli:test:       Tests  3828 passed | 1 skipped (3829)
@jinn/web:test:  Test Files  122 passed (122)
@jinn/web:test:       Tests  1275 passed (1275)
 Tasks:    2 successful, 2 total
Cached:    0 cached, 2 total

pnpm build — the root script is turbo build && node scripts/sync-web-dist.mjs;
appending --force to pnpm build passes the flag to the second command, so the
chain was expanded to force the build itself:

 Tasks:    2 successful, 2 total
Cached:    0 cached, 2 total
  Time:    4.243s

===SYNC-WEB-DIST===
synced packages/web/out -> packages/jinn/dist/web

No test was deleted; tests were only re-pointed at the new import paths.

---

Todo PLA-51. Base 23df25ed62acfa162a39923638eb14dbbf1d8bea, head
491e160e137bd6e759b69c3358658c354db76b26. For operator review — not merged.