feat(acp): add same-harness model fallback

[custard-pirate]

Summary

• add an optional BUZZ_ACP_FALLBACK_MODEL for same-harness failover
• activate the fallback after non-auth provider errors, fatal timeouts, or ACP transport failures
• preserve the fallback across slot respawns until the buzz-acp service restarts
• allow a silent hard-timeout batch one retry when a fallback has not yet been attempted
• document the new configuration and include the active fallback in startup summaries

Why

Today buzz-acp replaces a poisoned ACP subprocess but recreates it with the same model. A provider-side model stall can therefore leave an agent unavailable or retry the same unhealthy route. Operators can select another model manually, but there is no bounded automatic recovery path within an otherwise healthy harness and provider.

This change keeps the harness and provider fixed and changes only the desired model on the replacement slot. It intentionally does not implement cross-provider or cross-harness routing.

Behavior

• Primary failures switch to the configured fallback.
• The fallback remains selected for the process lifetime, avoiding model oscillation.
• Authentication failures retain their existing non-retryable behavior.
• If the fallback also fails, existing retry-budget and dead-letter behavior applies.
• Without BUZZ_ACP_FALLBACK_MODEL, behavior is unchanged.

Validation

• cargo fmt --all -- --check
• cargo clippy -p buzz-acp --all-targets -- -D warnings
• cargo test -p buzz-acp --lib — 671 passed
• cargo build --release -p buzz-acp
• live Goose/Ollama validation with a primary and fallback cloud model