feat: provider rotation strategy for agents

[alexsiri7]

Problem

Currently, each agent has a single provider field — resolved once at spawn time. For cost-conscious deployments, it would be useful to rotate providers across restarts. For example, a witness agent could randomly pick between gemini-flash and claude-haiku on each spawn, spreading token usage across providers and providing resilience when one provider hits rate limits.

Proposal

Add providers (list) and provider_strategy fields to the Agent config:

[[agent]]
name = "witness"
scope = "rig"
providers = ["gemini-flash", "claude-haiku"]
provider_strategy = "random"

Behavior:

• When providers is set (list), ResolveProvider() picks one based on provider_strategy
• When provider is set (string, existing behavior), nothing changes — full backward compatibility
• provider_strategy is extensible (template method / strategy interface) but only random is implemented initially
• Selection happens at spawn time in the controller, so each restart naturally gets a new provider

Config precedence: providers + provider_strategy takes priority over provider when both are set.

Scope

• Add Providers []string and ProviderStrategy string to Agent struct
• Add ProviderStrategy interface with Select(providers []string) string
• Implement RandomStrategy
• Update ResolveProvider() to check for multi-provider config
• Update AgentPatch, AgentOverride, apply functions, pool deep-copy
• Tests for strategy selection, config parsing, backward compat

[alexsiri7]

Additional requirement: when the reconciler restarts a session (e.g. after tmux pane dies from quota exhaustion), it should re-roll the random provider selection instead of reusing the provider stored in the session bead. Currently quota-blocked sessions restart with the same blocked provider in an infinite cycle. A quota-reap exec order (every 3m) can kill them, but without re-rolling the provider it's ineffective.

[alexsiri7]

Design: Stable Provider Selection with Re-roll on Fresh Creation

Problem

RandomStrategy.Select() is called inside ResolveProvider() → resolveTemplate() on every reconcile tick. With multiple providers, each tick may pick a different provider → different command string → different CoreFingerprint → constant config-drift restarts. This makes multi-provider lists unusable.

Design

Principle: Provider is selected once at session creation, stable while running, and re-rolled only on fresh session creation.

1. Store selected provider in bead metadata

When materializeSessionForAgentConfig or materializeSessionForTemplateWithOptions creates a new session bead, store the resolved provider name:

bead.Metadata["provider"] = resolved.Name

2. On reconcile tick: read stored provider, don't re-roll

In resolveTemplate (or its caller in build_desired_state.go), when computing desired state for an existing session bead, read bead.Metadata["provider"] and use it directly instead of calling ResolveProvider with the random strategy. This keeps the fingerprint stable.

Only call RandomStrategy.Select() when no existing bead is found (i.e., fresh session creation).

3. Exclude provider from fingerprint (alternative approach)

Alternatively, exclude the provider/command from CoreFingerprint. The reconciler would only detect drift on prompt, env, workdir — not provider changes. Simpler but less precise.

Recommended: approach #2 (read from bead). It's explicit and doesn't weaken drift detection for other command changes.

4. Quota-kill forces re-roll

When a session is killed due to quota exhaustion (detected by quota-reap order or health.sh), the kill path should close the session bead (not just kill tmux). This forces the reconciler to create a fresh bead → fresh ResolveProvider call → new random pick.

Concretely:

• quota-reap.sh (or health.sh --fix) detects quota-blocked session
• Calls gc session close <id> (not just tmux kill-session)
• Reconciler sees missing desired session → creates new bead → calls ResolveProvider → random picks from providers list → likely different provider

5. Session resume compatibility

Claude Code's --resume flag reuses an existing conversation. When provider changes on re-roll, the session must start fresh (no --resume). This is already handled by wake_mode = "fresh" agents. For agents with resume, closing the bead (step 4) naturally prevents resume since there's no session to resume.

Implementation Checklist

• In resolveTemplate: accept optional existingProvider string param; if set, override ResolveProvider to use that provider name directly
• In build_desired_state.go / discoverSessionBeads: pass bead.Metadata["provider"] to resolveTemplate for existing sessions
• In materializeSessionForAgentConfig: store resolved.Name in bead metadata
• In quota-reap.sh: use gc session close instead of tmux kill-session for quota-blocked sessions
• Tests: verify fingerprint stability across ticks with multi-provider config
• Tests: verify fresh bead creation re-rolls provider