beta.25 cold-start caches break outside a Workers isolate — ~25 core unit tests fail on a clean checkout

[mmcintosh]

Summary

On a clean checkout of main, npm test in packages/core reports ~25 failing unit tests. They are not flaky and not environmental — three per-isolate cache / context assumptions introduced by the beta.25 cold-start work are correct inside a live Workers isolate but wrong outside one (the test harness / any non-Workers runtime).

Root causes

1. document-scalar-schema.ts — module-level PRAGMA cache leaks across databases. The column/index cache is a module-level Set, so in tests the second in-memory DB "already has" its q_* generated columns per the cache, the ALTERs are skipped, and every generated-column read fails with no such column: q_*. ~16 failures across 5 real-SQLite suites.
2. plugin-middleware.ts — isPluginActive cache keyed by pluginId only. One mock DB's active status bleeds into the next test's DB. ~7 failures.
3. api.ts + catalog.ts — c.executionCtx throws with no ExecutionContext. Hono's getter throws under app.request() (no ExecutionContext), 500-ing the cached-collection read path. 2 failures.

Impact

• CI on main is red for anyone running the core unit suite; the failures obscure real regressions.
• The failures are in the test/runtime-adaptation layer only — production Workers behavior is unaffected (a live isolate has one DB binding and a real ExecutionContext).

Proposed fix

Keep each production optimization, make it correct across databases/runtimes: WeakMap keyed by the D1 binding for both caches (preserves the per-isolate dedup — one bootstrap reuses one env.DB), a generation-stamp invalidation for the plugin-status cache, and a safeExecutionCtx() guard so the KV catalog warm degrades to a no-op when there is no ExecutionContext.

A PR implementing exactly this is ready. It touches 4 files, adds no new tests (it repairs existing ones), and does not touch bootstrap.ts or the first-boot sequence.