Hydrate the OpenRouter catalog on cold runtime resolution

[16francej]

Problem

Selecting a dynamic OpenRouter catalog model (e.g. stealth/ox-alpha) intermittently fails a turn with:

runtime pi/stealth/ox-alpha is not approved

The selection is approved and present in the catalog; the failure is timing-dependent.

Cause

Dynamic OpenRouter models are registered into the process-local model registry only after selectableModelCatalog() fetches the catalog. #656 added a pre-warm on the API turn entrypoint (app-turn.ts), but the harness router's resolution path in wiring.ts resolves the runtime again at run execution time with no warm-up. On a cold process (fresh worker start, or one that never served the picker), resolveModel() returns undefined, modelSupportedByHarness() fails, and harness-router.ts throws — so the same selection works when the process is warm and fails when it isn't, which is why it looked fixed and regressed.

Fix

• resolveRuntimeChoiceDurable accepts an optional hydrateModelCatalog callback and awaits it before resolving whenever any candidate model (requested, scope, or org selection) is unknown to the local registry.
• wiring.ts passes a hydrator that fetches the OpenRouter catalog when an OpenRouter key is available, so the harness router path self-heals on cold processes.
• A warm registry never triggers a fetch (verified in the test).

Testing

• new regression test in test/runtime-selection.test.ts: cold resolution without a hydrator falls back; with a hydrator it resolves the dynamic model (both via stored selection and explicit request); warm registry skips hydration
• test/runtime-selection.test.ts + test/dynamic-openrouter-model.test.ts: 8/8 pass
• tsc --noEmit, oxlint, prettier clean on touched files

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}