[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.