Remote Control: "New session" on claude.ai/code attaches to the environment's most recent session instead of creating a new one

### Preflight Checklist

- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code (2.1.259)

### What's Wrong?

On claude.ai/code with a **Remote Control** environment selected in the composer (` · `, server started with `claude remote-control --spawn same-dir`, CCR v2 multi-session bridge), clicking **New** (or the project's **+**) and sending a message does **not** create a new session. The URL switches to the environment's most recently used session (`/code/session_…`) and the message is appended there.

The bridge on the PC shows **no** new `work/poll -> 200 workId=cse_…` and **no** `Spawning sessionId` for a new session. It shows either nothing (the message went into a live session) or `Previously completed workId=… was re-queued by the server` (the message revived a session whose worker had already exited with a non-zero code).

Reproduced 4 times on 2026-09-04 (KST):

1. 10:48 — the most recent session had crashed (`exited status=failed exit_code=255`). "New" + send → the dead session was re-queued and the message landed there.
2. 11:01 — same session after the bridge had POSTed `work/stop` for it. Send hung at "connecting…" for 30+ s and never reached the bridge.
3. 13:25 — the most recent session was **alive and mid-turn** (a long tool-using turn). "New" + a YouTube link → landed in that session (`error_during_execution … result_type=user`).
4. 13:38 — fresh `/code` page with no session open. "New" + send → landed in the live session with the most recent activity.

What does work:
- Archiving the most recent session in the sidebar → the very next "New" creates a real new session (`Spawning … cse_`, reply in ~20 s). Verified twice.
- Creating a session from the PC with `POST /v1/code/sessions {title, environment_id, config:{cwd}}` → the bridge spawns it within ~5 s and it works from the web.
- Resuming older sessions from the sidebar works normally.

Browser `localStorage`/`sessionStorage` contain no per-environment "current session" key, so the routing seems to be in app state or server-side. The bridge was polling normally the whole time (capacity 32, 4–6 sessions running).

### What Should Happen?

"New" with a Remote Control environment should always create a new session in that environment, regardless of whether the most recent session is alive, idle, or failed. Users should not have to archive the previous session to get a new one.

### Error Messages/Logs

Bridge debug log (`--debug-file`), case 1 — user pressed "New" and sent at 10:48; no new session, old workId re-queued:

```
2026-09-04T01:34:05.303Z [DEBUG] [bridge:session] sessionId=[REDACTED] workId=cse_01Xt1nqxYfBEy5LhttNjRXSV exited status=failed duration=18m 43s
2026-09-04T01:34:05.328Z [DEBUG] [bridge:api] POST .../work/cse_01Xt1nqxYfBEy5LhttNjRXSV/stop force=false
2026-09-04T01:48:24.316Z [DEBUG] [bridge:api] GET .../work/poll -> 200 workId=cse_01Xt1nqxYfBEy5LhttNjRXSV type=session sessionId=[REDACTED]
2026-09-04T01:48:24.322Z [DEBUG] [bridge:work] Previously completed workId=cse_01Xt1nqxYfBEy5LhttNjRXSV was re-queued by the server, handling as new work
2026-09-04T01:48:25.747Z [DEBUG] [bridge:session] Spawning sessionId=[REDACTED] sdkUrl=https://api.anthropic.com/v1/code/sessions/cse_01Xt1nqxYfBEy5LhttNjRXSV
```

Case 3 — "New" + message while the latest session was mid-turn (13:25):

```
2026-09-04T04:25:50.985Z [DEBUG] [bridge:activity] sessionId=[REDACTED] result subtype=error_during_execution error="[ede_diagnostic] result_type=user last_content_type=n/a stop_reason=tool_use"
2026-09-04T04:26:52.533Z [DEBUG] [print.ts] end_session received, reason=archived
2026-09-04T04:27:01.254Z [DEBUG] [bridge:api] GET .../work/poll -> 200 workId=cse_019JgNXdxu57wtEvTXWL8g4j type=session <- new session only after the user archived the old one
```

After archiving (11:05), the same composer produced a real new session:

```
2026-09-04T02:05:04.020Z [DEBUG] [bridge:api] <<< {"id":"cse_01QwGkuBb8wrs1eg8FiBzfLF","type":"work","environment_id":"env_…","state":"queued",...}
2026-09-04T02:05:04.731Z [DEBUG] [bridge:session] Spawning sessionId=[REDACTED] sdkUrl=https://api.anthropic.com/v1/code/sessions/cse_01QwGkuBb8wrs1eg8FiBzfLF
```

### Steps to Reproduce

1. On Windows, run `claude remote-control --spawn same-dir` (default capacity) in a project directory.
2. On claude.ai/code, create a session in that environment and use it (send any message). Leave it open or let it finish; it can also be a session whose worker crashed.
3. Go back to `/code` (or click the project's **+** / **New**), keep the same Remote Control environment selected, type a message, send.
4. Observe: the URL becomes the previous session's URL and the message is appended there; the bridge log shows no new `Spawning`.
5. Archive that previous session in the sidebar, repeat step 3 → a new session is created.

### Claude Model

Fable 5.1 (also reproduced with the default model)

### Is this a regression?

Not sure — the sidebar layout of claude.ai/code changed the same day (sessions now grouped by day), which suggests a recent web deploy.

### Last Working Version

Unknown

### Claude Code Version

2.1.259 (native install)

### Platform

Windows 10 Pro 10.0.19045, Chrome (claude.ai/code). Plan: Max.

Start by tracing session creation from claude.ai/code through POST /v1/code/sessions, then compare it with the GET /work/poll and work/stop flow used by the Remote Control bridge. Reproduce with `claude remote-control --spawn same-dir` and confirm that New produces a distinct queued work item and session without archiving the previous one.

索引モデルが issue の本文から書いたものです。