ACP `load_session` reloads the session without messages before checking pending tool confirmations, so the #11685 re-prompt and state-machine resume never fire

**Describe the bug**

`handle_load_session` (`crates/goose/src/acp/server/load_session.rs`) reloads the session after preparing the agent:

```rust
session = self
.session_manager
.get_session(&session_id_str, false) // include_messages = false
.await
.internal_err_ctx("Failed to reload session")?;
```

With `include_messages = false` the returned `Session` has `conversation: None` (`session_manager.rs`, `get_session`). #11685 (14c00a4) moved `resend_pending_tool_permissions` to after that reload and added the `should_resume_state_machine` check next to it. Both read `session.conversation`, so `pending_confirmations` is always empty and `has_unapplied_tool_confirmation_response` is never evaluated.

Net effect on `main` with `GOOSE_STATE_MACHINE=1`:

1. Reopening a session that was persisted while waiting for a tool approval does not re-send `session/request_permission`.
2. Reopening a session whose approval response was persisted but whose tool never answered does not resume the state-machine turn.

The handler has no test that goes through a session with messages; `pending_permissions_are_limited_to_the_active_turn` only covers the pure function.

---

**To Reproduce**

Live, debug build of `main` @ 794b04a, `GOOSE_STATE_MACHINE=1`, `GOOSE_MODE=approve`, `goose acp --with-builtin developer`, driven over stdio by a small ACP script, with a mock OpenAI endpoint that answers the first prompt with one `shell` tool call.

1. `session/new`, then `session/prompt`. goose sends `session/request_permission` for the shell call. `kill -9` goose while the request is pending.
Persisted: user prompt, assistant `toolRequest`, assistant `actionRequired/toolConfirmation`.
2. Start `goose acp` again and `session/load` the same session.
Result: history is replayed, `session/load` returns, and nothing else happens (waited 25 s). No `session/request_permission`.
3. Change the reload to `get_session(&session_id_str, true)` and repeat 1 and 2.
Result: `session/request_permission` arrives right after the replay, as #11685 intends.

---

**Expected behavior**

On load, pending confirmations are computed from a session that has its messages, so the permission is re-sent (or the state-machine turn resumed) as described in #11685. Either keep using the pre-reload `session` for that computation (what the code did before #11685) or reload with `include_messages = true`. A handler-level test with a persisted `actionRequired/toolConfirmation` message would have caught this.

Heads-up: with this fixed, the approved-but-unanswered path re-executes the tool (separate issue: #11808).

---

**Please provide the following information**
- **OS & Arch:** macOS arm64 (Darwin 25.4)
- **Interface:** ACP (`goose acp`), state-machine loop (`GOOSE_STATE_MACHINE=1`)
- **Version:** main @ 794b04a (2026-09-03); introduced by 14c00a4 (#11685)
- **Extensions enabled:** developer
- **Provider & Model:** provider-independent; mock OpenAI-compatible endpoint

---

Der Fehler liegt in crates/goose/src/acp/server/load_session.rs in der Funktion handle_load_session. Sie lädt die Sitzung mit include_messages = false neu, wodurch verhindert wird, dass die Konversation geladen wird. Dadurch wird die in #11685 hinzugefügte Logik von resend_pending_tool_permissions und should_resume_state_machine beeinträchtigt. Untersuche zunächst den Aufruf zum Neuladen der Sitzung und die Funktion get_session in session_manager.rs. Die Behebung besteht darin, entweder die Sitzung vor dem Neuladen für die Prüfung auf ausstehende Bestätigungen zu verwenden oder sie mit include_messages = true neu zu laden. Ein Test mit einer persistierten actionRequired/toolConfirmation-Nachricht sollte hinzugefügt werden, um eine Regression zu verhindern.

Vom Indexierungsmodell aus dem Issue-Text verfasst.