fix(acp): resolve provider default model instead of leaking sentinel "current"

[morgmart]

Summary

The ACP_CURRENT_MODEL sentinel value "current" leaks unresolved to the Databricks AI Gateway (and other non-ACP providers), causing a 404 "Resource not found" error on every new session for affected users. This is the most-reported issue in the #berd-internal-beta Slack channel over the past week (7+ users hit it between June 29 – July 7).

Linear ticket: BOT-1172

The error users see

Request failed: Resource not found (404) at
block-lakehouse-production.cloud.databricks.com/ai-gateway/mlflow/v1/chat/completions:
'current' does not exist.

Every new session fails. Existing sessions work fine. The workaround users found is toggling the model to a different one and back — but this is manual and doesn't fix the root cause.

Root cause

PR #9953 ("provider refactor: don't require a model config to create a provider", merged June 23) removed the sentinel resolution from AcpProvider::connect() and replaced it with apply_model_if_changed() — which explicitly skips when the model is "current" (early return). So the sentinel never gets resolved for non-ACP providers.

The primary leak point is update_provider in crates/goose/src/acp/server.rs. When a user switches providers via set_config_option("provider", ...) without an explicit model, is_changing_provider is true and the default model is hardcoded to ACP_CURRENT_MODEL:

} else if is_changing_provider {
    ACP_CURRENT_MODEL.to_string()
}

This sentinel is only valid for ACP providers (claude-acp, codex-acp, etc.) where the agent manages its own model selection. For non-ACP providers like databricks_v2, the literal string "current" gets sent to the gateway → 404.

Changes

1. Primary fix — crates/goose/src/acp/server.rs (update_provider)

Resolve the default model from the new provider's registry entry instead of hardcoding the sentinel. For ACP providers, entry.metadata().default_model is "current" (no behavior change). For non-ACP providers, it resolves to the actual default model (e.g. databricks-gpt-5-5).

2. Defense-in-depth — crates/goose/src/agents/agent.rs (restore_provider_from_session)

For sessions already saved with the sentinel on a non-ACP provider, resolve the default model from the registry on session restore. This fixes existing affected users on next app restart without needing to toggle models manually.

Why this affects so many users right now

The sentinel is the default model for any fresh install or after config resets. The Goose → Berd rename/reconfiguration reset many users' configs, which is why reports started June 29 (a few days after the June 23 merge) and are still coming in.

Validation

• ✅ cargo check -p goose — clean
• ✅ cargo clippy -p goose -- -D warnings — no warnings
• ✅ cargo test -p goose -- providers — 334 passed (4 pre-existing JWT/crypto failures unrelated to this change)

[jamadeo]

Thanks for the fix @morgmart, I can reproduce the issue and this does indeed fix it. I think we can probably improve over using a sentinel value here to indicate provider-managed models, but that can be done separately.