Failed provider restore poisons the agent cache: session stuck at "Provider not set" until daemon restart, even after credentials are fixed

**Describe the bug**

When a session's saved provider fails to be recreated during session load — e.g. AWS Bedrock with an expired SSO token — the desktop shows `Failed to get provider while loading ACP session: Provider not set`, and the session stays permanently unloadable until the daemon is restarted. Retrying after fixing the credentials (`aws sso login`) does not help.

Root cause (traced in `goose serve` logs and code):

1. `AgentManager::create_agent_locked` attempts `restore_provider_from_session`. On a non-auth error it only logs a warning and continues (`crates/goose/src/execution/manager.rs`):
```
INFO Restoring evicted session 20260909_42 (provider: Some("aws_bedrock"))
WARN Failed to restore provider for session 20260909_42: Could not create provider: Failed to load AWS credentials: an error occurred while loading credentials. Make sure to run 'aws sso login' ...
```
2. The agent is then inserted into the LRU cache **without a provider** (there is no default-provider fallback in the desktop/ACP path).
3. Every subsequent `session/load` hits the cache fast path in `get_or_create_agent`, gets the broken agent back, and fails at `agent.provider()` in `crates/goose/src/acp/server/load_session.rs` with the opaque `Provider not set`. The provider restore is never attempted again — note the missing `Restoring evicted session` line on retries:
```
06:13:50 INFO Restoring evicted session 20260909_42 (provider: Some("aws_bedrock"))
06:13:50 WARN Failed to restore provider for session 20260909_42: ... Failed to load AWS credentials ...
06:13:50 ERROR ACP load_session failed ... "Failed to get provider while loading ACP session: Provider not set"
06:13:59 ERROR ACP load_session failed ... "Provider not set" <- retry, no restore attempt
06:31:38 ERROR ACP load_session failed ... "Provider not set" <- retry after `aws sso login`, still no restore attempt
```

**To Reproduce**

1. Configure `aws_bedrock` as the provider (SSO-based AWS profile).
2. Open sessions in Goose Desktop, let the SSO token expire (or revoke it).
3. Click a previous session → `Failed to Load Session: ... Provider not set`.
4. Run `aws sso login`, click Retry → same error forever; only restarting Goose Desktop helps.

**Expected behavior**

- The surfaced error should be the actual restore failure (`Failed to load AWS credentials ...`), not the secondary `Provider not set`.
- Retrying a session load after fixing credentials should re-attempt the provider restore and succeed without restarting the daemon.

**Proposed fix**

In `create_agent_locked`, propagate the restore error instead of caching a provider-less agent when the session record names a provider and no default-provider fallback rescued it. Auth-required errors already propagate this way; this extends the same shape to other provider-creation failures. I have a patch with a regression test ready and will open a PR referencing this issue.

**Please provide following information:**

- OS & Arch: macOS 15 (Darwin 25.6.0), arm64
- Interface: UI (Goose Desktop, ACP) — CLI is affected the same way through `AgentManager`
- Version: 1.50.0
- Extensions enabled: developer, skills, todo, orchestrator, summon, code_execution, analyze
- Provider & Model: aws_bedrock, eu.anthropic.claude-opus-5

El bug está en `crates/goose/src/execution/manager.rs` en `AgentManager::create_agent_locked`. Revisa la lógica de `restore_provider_from_session` y cómo se manejan los errores. La caché de agentes queda envenenada cuando un proveedor no se puede restaurar. La corrección probablemente implique propagar el error de restauración en lugar de insertar un agente sin proveedor en la caché LRU. Revisa `crates/goose/src/acp/server/load_session.rs` para la llamada `agent.provider()` que falla. Se debería agregar una prueba de regresión. Ejecuta el daemon localmente y simula la expiración de un AWS SSO token para reproducirlo.

Escrito por el modelo de indexación a partir del texto del issue.