Opening a persisted general chat can fail with “session not found” and create a blank replacement

### Short summary

After restarting the app or machine, opening an existing persisted general chat can fail to resume and silently redirect to a new blank chat while the original remains inaccessible.

### Affected version or release

1.0.23

### Installation context

GitHub Copilot app on Windows x64, OS build 26200.8875. Persisted local general chat with a long conversation history.

### What happened?

After restarting the app or machine, I selected a previously saved general chat from the sidebar.

The UI displayed “Resuming session,” but the original conversation did not open. The resume operation repeatedly failed with `session not found`.

After the final failure, the application created a replacement CLI session and opened a new blank general chat. The original chat remained visible in the sidebar with an error indicator but could not be opened.

Opening the original chat again reproduced the same resume failure and triggered another replacement CLI-session creation. At least one replacement appeared as a new blank chat in the UI.

### Steps to reproduce

This reproduces repeatedly for the affected persisted chat:

1. Restart the GitHub Copilot app or the machine.
2. Select a long, previously saved general chat from the sidebar.
3. Observe “Resuming session.”
4. Wait for the restoration attempt to finish.
5. Inspect the original sidebar entry and the chat that opens.
6. Select the original chat again.

Actual:
- Resume fails with `session not found`.
- The original chat remains unopened and shows an error indicator.
- The application creates a replacement CLI session.
- At least one replacement opens as a new blank general chat.
- Reopening the original repeats the failure and replacement-session creation.

Expected:
- The original chat opens with its persisted conversation history.
- If restoration cannot succeed, the app preserves the original entry and shows a recoverable error.
- A failed resume must not silently create or redirect to an unrelated blank chat.

### Expected behavior

A persisted general chat should resume with its existing history after an app or machine restart.

If the underlying session cannot be restored, the app should keep the user on the original chat and surface an actionable recovery error. It should not replace the failed session with a blank chat or create additional orphaned sessions.

### Additional context

#### Sanitized log sequence

The local application log shows:

- `resume_session` with `include_history=true`
- `resume_session failed` with `session not found`
- retries 1/3, 2/3 and 3/3
- final `failed to resume session`
- `Recreating session old_session_id=`
- `CLI session created cli_session_id=`

The same failure occurred again when reopening the original chat.

#### Persisted state

The original application database record still exists and is not archived or marked interrupted.

At the time of inspection:

- `was_interrupted=0`
- `context_current_tokens=624190`
- `context_input_token_limit=922000`
- `context_conversation_tokens=591085`

This makes simple context-window exhaustion unlikely. The application-level session record and local session state remain present, but the CLI resume path cannot resolve the session.

#### Possible diagnostic clue

During each resume attempt, the logs show a warm CLI process being reused from a pool associated with the shared general-chat working directory. Multiple general chats use that directory.

This may indicate an app-to-CLI session mapping, process-affinity or shared-working-directory issue. This is only a diagnostic lead; causality is not confirmed.

The failed-resume fallback is independently problematic because it creates a blank replacement instead of preserving the original chat or surfacing a recoverable error.

#### Impact

The saved conversation becomes inaccessible through the UI, which appears to the user as data loss. Repeated attempts can also create replacement sessions and additional blank-chat clutter.

Related:

- #924 is the canonical general restore-failure report.
- #2040 reports failed restoration and disappearing history on v1.0.23.
- #898 reports unsolicited “New chat” entries through a different trigger.
- The v0.2.8 release notes describe a previously fixed resume/recreation bug with empty replacement sessions:
https://github.com/github/app/releases/tag/v0.2.8

Raw logs are not attached because they contain local paths, session IDs and conversation-related data.

Start by tracing the logged resume_session flow, its retries, and the failed-resume fallback that recreates a CLI session; compare the behavior with #924, #2040, and the v0.2.8 release notes. Done means a persisted chat either resumes with its history or remains selected with an actionable error, without creating a blank replacement or orphaned session.

Written by the indexing model from the issue text.