feat: per-child provider/model on dispatched workers (collab sessions P0)

[saucam]

P0 of docs/collaborative-session-design.md §11, off the design merged in #244.

Exit criterion: a dispatched worker runs on a chosen non-default backend. Met and proven — see Verification.

Before this, spawnWorker() passed no providerId, so every dispatched worker silently landed on the daemon default no matter what was intended. This makes the backend a per-child property, which is what lets a collaborative session put its roles on different vendors.

What changed

File	Change
models.ts	resolveModelIdForProvider() + CLAUDE_PROVIDER_ID
store.ts	provider/model columns on dispatch_tasks (inline CREATE + additive ALTER)
dispatch.ts	Dispatcher.enqueue carries and audits the selection
fleet.ts	fleet_spawn takes provider/model; new fail-closed resolveBackend dep
session-manager.ts	spawnWorker honors the selection + claim-time re-validation
session.ts	model default resolved against the effective provider

Three findings beyond the stated scope

1. ProviderRegistry.resolve() doesn't throw on an unknown id — it logs a warning and falls back to the default. Combined with the API backends registering only when their env key is present, a task naming a provider that no longer registers (any restart where a key went missing) would have run its worker on claude while reporting success. Now re-validated at claim time and failed terminally, next to the existing workdir re-check.

2. Claude aliases leaked across backends. config.session.defaultModel is a global, but resolveModelId expands against the Claude catalog — so opus on a gemini session became claude-opus-4-8 inside a Google API call. Claude-shaped values now resolve to null on other backends (provider picks its default); provider-native ids pass through untouched.

3. Latent inconsistency in session.ts. Model resolution keyed off the requested provider id while construction used registry.defaultId. Those differ whenever the caller omits a provider, and coincide today only because createDefaultProviderRegistry hardcodes "claude". Both now use the effective id.

Verification

• Full suite 1842 pass / 0 fail (1827 baseline, +15), typecheck + biome + bun build all clean.
• New src/tests/dispatch-per-child-provider.test.ts drives a real two-backend ProviderRegistry rather than _testProviderFactory — that injects one mock into every session and bypasses Session#createProvider, which is the path under test.
• Mutation-checked, so the tests aren't vacuous: reverting the wiring fails 4 of the 8 new tests, and the unregistered-provider task comes back running — confirming the silent wrong-vendor spawn is a real failure mode, not a hypothetical.

Scope notes

• fleet_send deliberately takes no provider: it targets an existing session that already owns its backend.
• MODEL_CATALOG is stale (opus → claude-opus-4-8, "Opus 4.8"). build(deps): bump @anthropic-ai/claude-agent-sdk to 0.3.220 for Claude Opus 5 #246 bumps the SDK for Opus 5 but touches only package.json/bun.lock. Left alone — changing what opus resolves to affects every session, well outside P0. Follow-up.
• Migration is additive; NULL preserves the pre-collaboration "daemon default" meaning for queued tasks written by an older daemon.
• Next: P1 (collaboration on SessionCreateMsg), which triggers the codeoid-ui crates/codeoid-protocol lockstep. Non-Claude orchestrators remain Support non-Claude orchestrators for collaborative sessions (mountable fleet MCP) #245.

🤖 Generated with Claude Code

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.