[BUG] Desktop app resumes an older session; large session .jsonl files get mtime updated days after their last message

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

On launch, the Claude Code **desktop app (macOS)** opens a session from ~2 weeks ago instead of the session I used the previous day. This has happened repeatedly over the past several days.

No data is lost — all session files are present in `~/.claude/projects//`. The problem is *which* session gets resumed.

While investigating, I found a possibly related anomaly: **only the large session files have an `mtime` far in the future relative to their last message.** The two small files have `mtime` ≈ last message. If session selection is based on file `mtime`, this would explain resuming the wrong session.

All timestamps below are **UTC**. `last_msg` = newest `timestamp` field inside the `.jsonl`; `mtime` = filesystem modification time.

| session id (prefix) | size | last_msg (inside file) | file mtime | drift |
|---|---:|---|---|---|
| `1b3adcf6` | 10.6 MB | 2026-08-20T12:55:45Z | 2026-08-20T12:55:45Z | none |
| `9631efdd` | 0.2 MB | 2026-07-21T22:42:46Z | 2026-07-21T22:43:01Z | none |
| `4bd8e77e` | **54.9 MB** | 2026-07-10T13:22:22Z | **2026-08-12T14:13:40Z** | **+33 days** |
| `d15a95c5` | **108.9 MB** | 2026-08-06T04:16:27Z | **2026-08-18T09:37:19Z** | **+12 days** |

**Pattern: only the two large files (54.9 MB, 108.9 MB) have drifted mtimes.** Nothing in those conversations was written after their `last_msg` — I did not open or use them on Aug 12 / Aug 18.

The app opens `d15a95c5`, whose newest message is 2026-08-06 — i.e. the session with the **most recent file mtime**, not the most recent conversation.

### What Should Happen?

Launching the desktop app should resume `1b3adcf6` — the session I used on 2026-08-19 (395 messages that day) and 2026-08-20, i.e. the session with the newest *message* timestamp.

### Error Messages/Logs

```shell
$ ls -la ~/.claude/projects//*.jsonl
(mtime, UTC)
2026-08-20 12:55 10.6 MB 1b3adcf6...jsonl
2026-08-18 09:37 108.9 MB d15a95c5...jsonl
2026-08-12 14:13 54.9 MB 4bd8e77e...jsonl
2026-07-21 22:43 0.2 MB 9631efdd...jsonl

Newest message timestamp inside each file (UTC):
1b3adcf6 2026-08-20T12:55:45Z <- mtime matches
9631efdd 2026-07-21T22:42:46Z <- mtime matches
4bd8e77e 2026-07-10T13:22:22Z <- mtime is 33 days later
d15a95c5 2026-08-06T04:16:27Z <- mtime is 12 days later

No error message is shown. The app simply displays the wrong conversation.
```

### Steps to Reproduce

1. In one project directory, have several sessions, at least one of them large (>50 MB)
2. Use the newest session on day N (in my case 2026-08-19, 395 messages that day)
3. Quit the desktop app
4. Relaunch the desktop app on day N+1
5. An older session is shown instead of the one used on day N

Note: I could not find a way to *force* the mtime drift — it appears to happen on its
own to large session files (two of mine drifted, on 2026-08-12 and 2026-08-18, with no
action from me). So step 1 may need a session file that has already drifted.

### Claude Model

_No response_

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

1.32885.1 (Claude desktop app, /Applications/Claude.app)

### Platform

Other

### Operating System

macOS

### Terminal/Shell

Other

### Additional Information

Platform: "Other" — I use the Claude desktop app with a Claude subscription, not the API / Bedrock / Vertex.
I am not using the CLI — only the desktop app. The "Terminal/Shell" field does not really apply.

The version above was read from the app bundle (/Applications/Claude.app), because `claude --version` is not available on this machine.

Note on the duplicate suggestions: I checked #88168, #75229 and #87335. None of them describes resuming the *wrong session* on launch, and none mentions the `mtime` drift on large session files, which is the part I think is the actual clue here.

Start by examining session files under ~/.claude/projects//*.jsonl and reproducing launch selection with several large sessions. Compare each file's filesystem mtime with its newest message timestamp, then trace the desktop app's resume-selection entry point; done means the session with the newest message is resumed despite mtime drift, with a regression test covering the case.

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