* fix(db): converge the install and upgrade schemas; stop ENOSPC from faking a divergence
The v3.8.50 publish run failed `check:install-upgrade` with "15 tables a CLEAN install
creates but an UPGRADE does not" (agentic_conversations, ccr_blocks, the whole Radar set,
jobs/job_runs, exclusive_connection_leases, …). None of them was missing.
Root cause, from the CI log (run 33104507735): the Phase B upgrade `npm install` hit
`npm warn tar TAR_ENTRY_ERROR ENOSPC: no space left on device` 5611 times, npm still exited
0, and the resulting truncated package made `omniroute serve` "exit with code 0 before
serving". No migration ever ran, so the database still held the 3.8.49 schema (115 tables)
and every post-133 migration table read as a divergence.
Verified against the real thing: booting the published omniroute@3.8.49 and replaying that
database through the current runner applies exactly 29 migrations and lands on the same
table set a clean install produces — the migration set was never at fault.
What changes:
- `163_model_capabilities.sql` — the one genuine convergence defect. The table was only
ever created by `ensureCapabilitiesTable()` on the first models.dev sync, so whether a
database has it depends on timing, not on the schema version. It is the residual the
gate reported. A migration makes both install paths deterministic.
- `check:install-upgrade` now fails on an ENOSPC-truncated install instead of measuring a
broken tree; authenticates its health probe with a minted internal-service token, so the
version assertion works against the health payload hardened by GHSA-mvf8-qc78-5mxm
(an anonymous caller gets no version — the same run also failed with "health reports
version undefined"); frees the ~3 GB clean-install tree before the upgrade phase; warns
when the temp filesystem cannot hold the run; prints the failing server's output; and
skips the convergence verdict when a phase never served, so a broken boot can no longer
manufacture a schema divergence on top of the real failure.
Tests: `tests/unit/db-install-upgrade-schema-parity.test.ts` pins the deterministic half of
the gate in milliseconds (every migration reachable on a clean install; model_capabilities
comes from the migration set; its DDL does not drift from the runtime helper), and the
ENOSPC guard is covered in the existing gate test.
* docs(db): record the real cause of the cache_metrics residual in the allowlist
The allowlist described every residual as "a CREATE that left the migration set in some
past cycle". cache_metrics never was in the migration set: it is created lazily by
ensureCacheMetricsTable() (src/lib/semanticCache.ts:34) the first time the semantic cache
runs, which is the same class as the model_capabilities divergence that blocked the v3.8.50
publish. Document both causes so the next residual is fixed with a migration where that is
the right answer, instead of reflexively allowlisted.
* docs: bump the migration count to 160 after 163_model_capabilities
check:docs-counts-sync enforces the shipped migration count as a STRICT claim in README.md,
AGENTS.md and llm.txt.
* docs(i18n): re-sync the 42 llm.txt mirrors after the migration-count bump
0ce21232db