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

---

The bug is in crates/goose/src/acp/server/load_session.rs in the handle_load_session function. It reloads the session with include_messages = false, which prevents the conversation from being loaded. This breaks the resend_pending_tool_permissions and should_resume_state_machine logic added in #11685. Start by examining the session reload call and the get_session function in session_manager.rs. The fix is to either use the pre-reload session for the pending confirmations check or reload with include_messages = true. A test with a persisted actionRequired/toolConfirmation message should be added to prevent regression.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.