feat(runtime): resolveAgentBackend — one shared backend-name → AgentExecutionBackend resolver

[drewstone]

What

Adds resolveAgentBackend(opts): AgentExecutionBackend — the AgentExecutionBackend sibling of the shipped resolveSandboxClient. It turns a --backend {router,tcloud,cli-bridge,sandbox} choice into the backend runChatThroughRuntime / runAgentTaskStream runs on.

Why

Five in-process eval products hand-roll the same backend-name → createOpenAICompatibleBackend branch, and the copies drift. Studied gtm (eval/kernel.ts buildAgentBackend), insurance (tests/eval/canonical.ts makeBackend), creative (eval/canonical-runner.ts buildBackend), legal (chat.ts defaultTCloudBackend): all three OpenAI-compat kinds are byte-identical apart from the kind label. This is the single generic resolver they will share (product migration is a later wave — no product repo touched here).

Union decisions

• router / tcloud / cli-bridge → createOpenAICompatibleBackend({ apiKey, baseUrl, model, kind: label ?? kind }). All three speak OpenAI-compatible POST {baseUrl}/chat/completions; router is the tcloud endpoint, cli-bridge fronts a harness CLI at its own /v1. cli-bridge requires model in the body — which this factory sends — so it routes here, never a transport that drops it.
• sandbox → the caller's sandboxBackend() seam. The product sandbox variant carries system prompt / workspace id / in-box D1 executor that do not belong in the substrate. Fail loud when the seam is absent (no silent fallback), matching resolveSandboxClient's sandbox contract.
• Common core vs product seam: pure backend selection is the core; product concerns (credit hard-cuts, fetch-capture shims, D1 platform wiring) stay product-side wrappers around the returned backend. The OpenAI-compat passthrough (tools, toolChoice, responseFormat, fetchImpl, retry) is forwarded verbatim so a product keeps its tool advertising / capture-fetch without re-opening the branch.

createCliBridgeBackend

The brief flagged a broken createCliBridgeBackend to fix/deprecate — it does not exist in agent-runtime (no export, no source; the only cli-bridge transport is bridgeExecutor in supervise/runtime.ts, used by resolveSandboxClient for the SandboxClient seam, a different path). Nothing to fix. cli-bridge correctly routes through createOpenAICompatibleBackend.

Tests / gate

• src/resolve-agent-backend.test.ts — 8 cases: each kind builds the right createOpenAICompatibleBackend config; label override; passthrough forwarding + omission (keeps tool-free request shape); sandbox seam honored + fail-loud.
• Local gate green: lint, typecheck (src+examples), full test suite (123 files / 1202 passed), build, verify:package, docs:check.

Additive, non-breaking. 0.82.0 → 0.83.0 (minor).

[tangletools]

✅ Auto-approved drewstone PR — d8b3e7d4

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-03T03:45:29Z}