feat(core): resolveActiveModelRefForChat — Phase 2.1 (stacked on #253)

[claudiusthebot]

What

Adds resolveActiveModelRefForChat() — the ModelRef-shaped
counterpart to core/active-model.ts's string-side
resolveActiveModelForChat(). Phase 2.1 of the architecture
unification plan.

Stacked on #253. Targets feat/agent-runtime-types-phase1 so the
diff is just the new resolver + tests. When #253 merges to main,
I'll re-target this PR to main.

No caller migration. The existing 5-step string-side chain stays
the single chain-of-truth. This PR adds a wrapping function that
enriches the returned id into a ModelRef carrying the metadata
downstream consumers (/status, /model menu, telemetry) currently
re-derive on the spot. Production behaviour is unchanged.

Why

Per the plan's Phase 2:

Create one resolveActiveModel() path that returns ModelRef.
Then convert /model, /status, chat query, heartbeat, and dream
to use it.

The plan splits naturally into 2.1 (introduce the function) + 2.2+
(migrate callers one at a time). Doing it as one giant PR would
touch 20+ call sites across bootstrap.ts, frontend/reasoning- levels.ts, frontend/telegram/{commands,callbacks,model-menu}.ts,
and frontend/discord/{commands,callbacks}.ts — too risky and too
hard to review.

What lands

src/core/agent-runtime/
  resolver.ts   resolveActiveModelRefForChat(chatId, backend,
                backendId, config) → { ref: ModelRef | null,
                source: ActiveModelSource } plus the
                getActiveModelRefForChat() convenience wrapper.
  index.ts      Re-exports the new symbols.

Enrichment strategy (deliberate fall-through)

1. backend.getModelInfo(id) — preferred, full metadata
2. backend.resolveModel(id) — exact — fallback, also full metadata
3. makeBareModelRef(backend, id) — last resort, identity-only
   (with cacheSupport stamped)

Each step's failure (returns null/throws) cleanly falls through to
the next, with warnings logged via logWarn.

cacheSupport propagation

Each ref carries the backend's cacheMetrics field — backends
report caching uniformly across their catalog today, so this is the
right place to stamp it.

ActiveModelSource → ModelSource mapping

Existing (string side)	New (ModelRef.source)
override-valid	chat
override-invalid-fallback	fallback
backend-canonical	backend-default
config-backend-defaults	config
config-legacy-global	config
none	(ref is null)

The config-* → config collapse is intentional. ModelRef.source
captures provenance (chat vs config vs backend); the fine-grained
ActiveModelSource tag returned alongside keeps the reason for
toast wording.

Invariants

• ref === null iff the 5-step chain returned model === null OR
  the supplied backendId is not a known BackendId.
• source is returned verbatim from the underlying chain so callers
  use identical toast wording in both APIs.

Tests

agent-runtime-resolver.test.ts (17 cases):

• Enrichment via getModelInfo (preferred)

• Enrichment via resolveModel (fallback)

• Bare ref fallback when neither catalog method matches

• cacheSupport propagation (read / readwrite / undefined → none)

• ref returned for trusted overrides when no resolveModel exists

• Source mapping — every ActiveModelSource → ModelSource branch

• Null edge cases (chain exhausts, unknown backendId, null backend)

• Survives getModelInfo throwing (falls through to resolveModel)

• Survives resolveModel throwing (falls through to bare ref)

• getActiveModelRefForChat convenience wrapper

• Full suite: 2917 / 2929 (12 pre-existing skips). 17 net new
  tests on top of Phase 1's 50.

• Type check passes (npm run typecheck)

• No new lint warnings (npm run lint — 18 pre-existing
  warnings, none in new code).

• Prettier clean on the new files.

Out of scope

• No caller migration. /status, /model, chat query, heartbeat,
  dream all keep calling resolveActiveModelForChat. Phase 2.2+
  converts them one at a time, each in its own PR.
• No changes to core/active-model.ts itself. The new module wraps,
  doesn't fork.

Stacked on #253. Refs docs/talon-architecture-unification-plan.md