Session tab rename is overwritten by a stale webview title; rename only appears after restarting VS Code

## Environment

- Extension: `anthropic.claude-code` 2.1.273 (darwin-arm64)
- CLI: 2.1.239
- VS Code: 1.138.0
- macOS 26.4.1 (Darwin 25.4.0)

## Summary

Renaming a session tab writes correctly to disk, but the extension then re-appends a stale title it is holding in memory, so the old name wins. The new name only becomes visible after quitting and reopening VS Code.

## Repro

1. Open a session tab and let the conversation run long enough for the CLI to emit `ai-title` records.
2. Rename the tab (`Claude Code: Rename Session Tab`). Observe the new name briefly.
3. Keep working in the session.
4. The tab reverts to a previously set name — not the one just typed.
5. Quit and reopen VS Code. The correct name now appears.

## Evidence

The two writers are distinguishable by JSON key order in the session transcript. `{type, sessionId, customTitle}` is `V6.renameSession`; `{type, customTitle, sessionId}` is the CLI echo via `renameSessionOnCli`. From one session's `.jsonl`, in file order:

```
A: cc tab <- user rename
B: cc tab
A: cc tab updates <- user rename
B: cc tab updates x3
A: cc tab update <- user rename
B: cc tab update
A: cc tab <- not typed by the user; stale value, written last
```

The final record is in the extension's own rename format and carries a title the user had set two renames earlier. Nothing on disk seeds it — grepping that value across VS Code storage, `~/.claude/ide`, `~/.claude/sessions` and `~/.claude/daemon` finds no match — so it is in-window state.

## Likely cause

The webview message handler writes the supplied title with no freshness check against what is already on disk:

```js
case "rename_session":
return this.renameSession($.request.sessionId, $.request.title);
```

A webview holding a stale title re-asserts it through this path and clobbers the newer rename. That also explains why a full restart fixes it: the webview is rebuilt and re-reads the correct title.

## Related: the persistence path never writes its own sidecar

Separately, `renameSession` appends a `custom-title` record to the transcript but never writes `//custom-title.json`. The tab-title resolver reads only the first and last 64 KB of the transcript (`fQ = 65536`) and consults that sidecar when the tail has no `customTitle` — but since nothing writes it, a rename is silently lost once ~64 KB of new transcript pushes the record out of the tail window. In one 1 MB transcript the rename sat 141 KB from EOF and the resolver fell through to the newest `ai-title`. Writing the sidecar during `renameSession` would fix that independently of the webview issue.

These are two distinct bugs; happy to split them if you'd prefer separate issues.

## Workaround

`Developer: Reload Window` after renaming.

Inspect the webview `rename_session` handler, `renameSession`, `renameSessionOnCli`, and the title resolver using `fQ = 65536`. Reproduce the behavior with a `.jsonl` transcript and verify that stale webview titles no longer overwrite newer renames, while `custom-title.json` preserves a rename after the record leaves the transcript tail.

Written by the indexing model from the issue text.