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

The bug is in `crates/goose/src/execution/manager.rs` in `AgentManager::create_agent_locked`. Look at the `restore_provider_from_session` logic and how errors are handled. The agent cache is poisoned when a provider fails to restore. The fix likely involves propagating the restore error instead of inserting a provider-less agent into the LRU cache. Check `crates/goose/src/acp/server/load_session.rs` for the `agent.provider()` call that fails. A regression test should be added. Run the daemon locally and simulate an AWS SSO token expiry to reproduce.

索引モデルが issue の本文から書いたものです。