[BUG] [VS Code] Renaming a session from the chat header reverts instantly (2.1.270 regression)

### 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?

Renaming a session from the title in the Claude view header shows the new name for one frame, then reverts. Renaming the same session from the activity-bar session list works.

The title **is** persisted — reload the window and the new name is there. Only the header view rolls back.

### Cause

`extension.js`, `Comm.renameSessionOnCli`:

```js
renameSessionOnCli($,Q){let X=(Y)=>{this.logger.log(`renameSession: the CLI did not take the title: ${Y}`)},
J=this.channelOnSession($);
if(J){J.query.renameSession(Q,$).catch(X);return} ... }
```

`query.renameSession` does not exist on the SDK query class. The call throws a synchronous `TypeError`, so `.catch(X)` never attaches — the throw escapes `Comm.renameSession`, `handleRequest` returns `{type:"error"}`, and the webview store's `renameBaseline` rollback restores the old title.

### Why only the header

The comm that owns the session's live CLI channel is the one that throws. A header rename originates from that comm, so it receives its own error and rolls back. A list rename originates from a comm with no channel; the fan-out's echo to the chat view is evaluated before the throwing call in the same comma expression, so the header has already adopted the new title. `adoptPersistedTitle` early-returns when `summary` already equals the new title, so the echo cannot repair the header path.

### What Should Happen?

The header shows the new title, matching what was persisted and what the activity-bar session list shows.

### Error Messages/Logs

```shell
Claude Code output channel, session id and titles redacted:

[info] Received message from webview: {"type":"request","request":{"type":"rename_session","sessionId":"","title":""}}
[error] Error processing client request: TypeError: J.query.renameSession is not a function
[info] Received message from webview: {"type":"interrupt_claude","channelId":"oes4etaaov"}
[warning] Channel not found: oes4etaaov
[info] Received message from webview: {"type":"request","request":{"type":"update_session_state","sessionId":"","state":"idle","title":"","idConfirmed":true}}

The trailing update_session_state carries the OLD title - that is the rollback.
Also note the interrupt_claude uses the requestId as a channelId and is not found;
that appears to be the generic error path misfiring on a request that never opened a channel.
```

### Steps to Reproduce

1. Open a session in the Claude sidebar view and send one message, so a CLI process is attached to it.
2. Click the session title in the view header, type a new name, press Enter.

**Expected:** the header shows the new title.
**Actual:** it reverts immediately. Renaming the same session from the activity-bar session list keeps the new name.

The attached CLI process matters — that is what makes this comm the channel owner and therefore the one that throws on itself.

### Claude Model

None

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

2.1.267

### Claude Code Version

VS Code extension 2.1.270 (CLI: 2.1.238)

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

### Regression detail

Not present in 2.1.267: `renameSessionOnCli` appears **0** times in that build, and the total `renameSession` occurrences in `extension.js` go from 6 (2.1.267) to 13 (2.1.270).

### Suggested check

The SDK query class exposes `generateSessionTitle`, `messageRated` and similar, but has no `rename*` member — so this looks like a call added against a method that was never implemented on that class, rather than a wiring mistake. Awaiting the call rather than using an unattached `.catch()` would at least surface it instead of failing silently into a rollback.

Start in extension.js at Comm.renameSessionOnCli and trace the rename request through Comm.renameSession and handleRequest. Reproduce the header rename with an attached CLI process, then verify the header remains consistent with the persisted title and activity-bar session list without the rollback error path.

Written by the indexing model from the issue text.