fix(smithy): spawn honors workspace defaultModels at session start

[komoreka]

Summary

session-manager.resolveExecutablePath has a 3-tier precedence chain (agent metadata → workspace defaults → provider built-in) but model resolution skipped the middle tier — it only read agent.metadata.model, never the workspace-level defaultModels[providerName] setting.

Two structural gaps reinforced this:

1. The server's ServerAgentDefaults type only persisted defaultExecutablePaths and fallbackChain. defaultModels and defaultProvider weren't stored at all.
2. useAgentDefaultsSettings in smithy-web was localStorage-only. Even if the operator set "Default model = Opus" in the settings UI, the value lived in their browser only — invisible to the daemon.

So the UI and the spawn path operated on disjoint state. Operators saw the workspace setting reflected in the UI dropdown but the daemon kept spawning Claude with the SDK's built-in default. Workaround was per-agent overrides via PATCH /api/agents/<id> for every agent.

Fix

Three pieces, mirroring how the existing resolveExecutablePath already works for executable paths:

1. Extend ServerAgentDefaults with defaultModels and defaultProvider. Persisted server-side via the existing /api/settings/agent-defaults endpoint with read + write validation. Backwards compatible with workspaces that have agent-defaults set via just defaultExecutablePaths.

2. New resolveModel(providerName, agentModel?) helper on SessionManagerImpl. Private method analogous to resolveExecutablePath. Used in both startSession and resumeSession so fresh starts and reconnects honor the same precedence:

   • options.model (call-site override) wins
   • then agent.metadata.model
   • then defaults.defaultModels[providerName]
   • then undefined → provider/SDK built-in default

3. Migrate useAgentDefaultsSettings to server-backed. Mirrors useExecutablePathSettings's pattern: fetch on mount, debounced PUT on change, localStorage as a hint cache only.

The CLI handler sf agent start was bypassing session-manager.startSession and calling spawner.spawn directly, so the fix is also wired into the CLI handler (second commit).

Files changed

• packages/smithy/src/services/settings-service.ts — type extension + read/write validation
• packages/smithy/src/services/settings-service.bun.test.ts — 7 new tests covering field persistence and validation
• packages/smithy/src/server/routes/settings.ts — accepts and validates the new fields on PUT
• packages/smithy/src/runtime/session-manager.ts — resolveModel helper, used in both spawn paths
• packages/smithy/src/runtime/session-manager.bun.test.ts — 6 new tests covering all resolution tiers
• packages/smithy/src/cli/commands/agent.ts — sf agent start CLI also reads workspace defaults
• apps/smithy-web/src/api/hooks/useSettings.ts — server-backed migration of the hook

Live verification

Captured during local dogfooding:

# Worker spawned via sf agent start (CLI path):
node-pty/spawn-helper ... bash -l -c 'claude' --dangerously-skip-permissions \
  --session-id 'c3ded67a-...' --model 'opus'

# Director auto-resumed by daemon after server restart (session-manager path):
/opt/homebrew/bin/claude --dangerously-skip-permissions --resume ae387c5a-... \
  --model opus Server restarted...

Both paths now pass --model from the workspace default. Inside the resulting director session, /model shows Opus (claude binary recognizes the opus alias).

Test plan

• bun test src/services/settings-service.bun.test.ts — 33 pass
• bun test src/runtime/session-manager.bun.test.ts -t 'model resolution' — 6 pass
• bun test src/runtime/session-manager.bun.test.ts — 89 pass (full file, no regressions)
• bun test packages/smithy/src — 1582 pass / 0 fail / 19 skip
• turbo run typecheck — 16/16 pass
• pnpm build — 13/13 pass

Migration note

Workspaces that previously set "Default model" via the localStorage-only UI will start fresh on first load after this lands (server-side store is empty). One-time disruption — users re-set in the UI and it's now persisted server-side where the daemon can read it.

Known small follow-up

The model registry endpoint (/api/providers/claude-code/models) returns an id: "default" sentinel meaning "use system default". If a user picks that sentinel in the dropdown, the literal string "default" gets passed to claude via --model default, which the binary doesn't recognize. Either filter out the "default" id at spawn time (pass undefined instead) or document the IDs the dropdown stores. Out of scope for this PR; happy to file a follow-up.

[komoreka]

Cross-reference: this PR has light overlap with issue #112 (cross-provider fallbackChain). They touch some of the same files (settings-service.ts, routes/settings.ts, useSettings.ts) but address independent gaps:

• fix(smithy): spawn honors workspace defaultModels at session start #113 (this PR): adds defaultModels + defaultProvider to ServerAgentDefaults and wires them into spawn-time model resolution. Migrates the smithy-web useAgentDefaultsSettings hook from localStorage-only to server-backed.

• feat(smithy): cross-provider fallbackChain failover — plan-aware rate-limit marking + Settings UI #112 (issue, not yet a PR): asks for cross-provider fallbackChain failover semantics + a Settings UI for the chain. Calls out that PUT /api/settings/agent-defaults does a full-replace where it should merge only-present fields.

This PR works around #112's Part B (full-replace bug) on the client side: the migrated useAgentDefaultsSettings does a GET-then-PUT to preserve defaultExecutablePaths and fallbackChain it doesn't own. So my changes don't depend on Part B landing, and they don't block it either — when #112 ships its server-side merge, my client GET becomes redundant but harmless.

No conflict with PR #110 (fix/silent-rate-limit-uses-agent-provider) — that one only touches dispatch-daemon.ts, no overlap.

Happy to bundle a small server-side fix for #112's Part B into this PR if maintainers prefer fewer round-trips, or keep them separate for cleaner review.