[BUG] [VS Code] Session list: hovering a row moves the focus highlight and never clears it

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

In the Claude Code session list in the activity bar, moving the mouse across rows moves the list's highlight to each row the pointer crosses, and it stays on the last one after the pointer leaves the list entirely.

The session you actually have open keeps its own active styling, but a second, stuck hover-colored band is left parked on an unrelated row (with that row's archive/rename actions permanently revealed). At a glance it is no longer clear which session is open.

This is not just a hover style. It is the list's keyboard-focus index, so arrow-key navigation afterwards resumes from whatever row the mouse last passed over rather than from the active session.

Likely mechanism, read out of the shipped bundle: each session row's mousemove handler writes the list's keyboard-focus index, and there is no corresponding mouseleave/mouseout handler anywhere in the session list to clear it. The index is simply left pointing at the last hovered row. The row's CSS `:hover` rule already supplies the same background and reveals the same row actions on its own, and it clears correctly on mouse-out.

### What Should Happen?

The highlight should indicate which session is actually open. Pointer feedback should be transient and clear when the pointer leaves the row, leaving the keyboard-focus index where the user last put it with the keyboard or a click.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

1. In VS Code, open the Claude Code session list in the activity bar, with several sessions present.
2. Open session A. Its row is highlighted as the active session.
3. Without clicking anything, move the pointer down across rows B and C.
4. Move the pointer off the list entirely.

Result: the highlight has followed the pointer and is left sitting on row C. Session A is still the open session. The highlight never returns to A.

Reproduces with the Claude view docked in the secondary (right) sidebar; the same handler is used regardless of where the view is docked.

### Claude Model

None

### Is this a regression?

No, this never worked

### Last Working Version

_No response_

### Claude Code Version

VS Code extension 2.1.270 (CLI: 2.1.238)

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

### Prior art in this repo

This same pattern has already been accepted and fixed on two other surfaces:

- #65349, shipped in v2.1.225: "Fixed hovering over a session in another project in the agents list changing the directory the next agent starts in" (the terminal agents list).
- v2.1.94: "[VSCode] Fixed dropdown menus selecting the wrong item when the mouse was over the list while typing or using arrow keys".

The VS Code sidebar session list appears to be the remaining surface where hover still overwrites keyboard focus.

### Related, but not duplicates

- #34060 reports the same end symptom in this widget, but its reproduction involves no mouse input at all (it is triggered by opening a new chat), and it is closed and locked, so this cannot be added there.
- The v2.1.261 fix for the session list's active-row highlight going stale covers a different trigger: an unfocused tab's session ID being corrected.

### Note on the suggested fix

Dropping the focus-index write from the mousemove handler appears to be sufficient on its own; the `:hover` CSS already covers the visual feedback. Note the handler also cancels a pending `scrollIntoView` on the same line, which does need to be kept.