ACP: session file written with agent-generated sessionId instead of the client-established one — session/load fails with "Invalid session identifier" (Zed as ACP client)

### What happened?

Gemini CLI 0.59.0 as ACP agent (--experimental-acp) under Zed 1.19.2+stable, Windows. Sessions never resume: session/load fails "Invalid session identifier". Cause: client and agent generate different sessionIds for the same conversation.

- Zed starts new chat. Session file written with agent's own ID: 5efa4992-15fe-4a64-97bb-382c6f09bfe0 (projectHash 375e9d..., startTime 2026-09-10T23:00:32.975Z). Conversation content intact in file.

- Zed later calls session/load with a different ID: 11977fe0-a2de-45d5-aa55-ab3ccc02e3a5. Response:

{"code":-32603,"message":"Internal error","data":{"details":"Invalid session identifier \"11977fe0-a2de-45d5-aa55-ab3ccc02e3a5\".\n Searched for sessions in C:\Users\\.gemini\tmp\\chats.\n Use --list-sessions..."}}

- Grepped session file for requested ID (11977fe0...): no match anywhere. File only ever had the agent's own ID.

- gemini --list-sessions (same project dir) does not list this session, despite the file existing and parsing. Only shows an older session which was done in a terminal.

- Tested on both Zed's managed ACP-registry install and a separate bun-installed gemini-cli 0.59.0. Same result. Same store: C:\Users\\.gemini, GEMINI_CLI_HOME unset.

- Reproduces consistently, every Zed agent-panel chat with gemini-cli fails to resume after the thread closes.

### What did you expect to happen?

Both sides to agree on the same ID

Session file on disk to contain the same ID passed to session/load.

session/load with that ID to restore the conversation.

### Client information

Client Information

\`\`\`console
> /about
About Gemini CLI
│ CLI Version 0.59.0
│ Git Commit fb0d535af
│ Model gemini-3.8-flash
│ Sandbox no sandbox
│ OS win32
│ Auth Method vertex-ai
│ GCP Project
\`\`\`

Platform: Windows 10.0.26200 Build 26200
ACP client: Zed 1.19.2+stable (agent panel, external agent via gemini.exe --experimental-acp)

### Login information

Logged in with Vertex AI. GOOGLE_GENAI_USE_VERTEXAI

### Anything else we need to know?

- Possibly related, same underlying bug class (session ID tracked independently in two places and diverging), different code path: #22604 , CLI's logger uses a process-generated session ID instead of the one being resumed, causing the same "ID that was never written to the store" failure. That's plain CLI resume; this report is the ACP/Zed equivalent of the same problem.
- Steps/IDs in Field 2 sufficient to reproduce.

Start by tracing the ACP session/load flow and the session files under .gemini\tmp\\chats, comparing the client-provided identifier with the identifier written by the agent. Reproduce with Zed and Gemini CLI 0.59.0, then verify that the requested ID is persisted, listed by --list-sessions, and restores the conversation through session/load.

Written by the indexing model from the issue text.