[FEATURE] Bridged sessions should show their real title on the paired device instead of <hostname>-<slug>

### Preflight Checklist

- [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)

### Problem Statement

I run Claude Code desktop on two machines under one account: a desktop and a laptop (hostname `INNK`), both Windows 11. Sessions started on the laptop are bridged to the desktop - their local records carry `bridgeSessionIds` and `remoteControlAutoEligible: true`.

In the desktop's session list, those laptop sessions cannot be identified by content:

- older ones show the auto-generated title exactly as it stood at creation, frozen from then on
- newer ones show a generated name such as `innk-composed-book` or `innk-adaptive-octopus`

Meanwhile the laptop's own record (`%APPDATA%\Claude\claude-code-sessions\\\local_.json`) always holds the meaningful title. After a rename it reads `"titleSource": "tool"`, with the previous name kept in `"previousTitles"`. That title never reaches the desktop, including after restarting the desktop app. This was consistent across every session I checked.

So the session list on the other machine cannot be used to find a past session, which is the main thing I need it for when moving between two machines. `-` tells me which machine ran it and nothing else. The useful value already exists on the originating side; it just does not travel.

### Proposed Solution

A session's title should be the same on every device that lists it, and a rename should follow it there.

Any one of these would be enough:

1. Propagate title updates - including `set_session_title` from the `ccd_session_mgmt` MCP tool - to the bridged / cloud session record.
2. Seed a bridged session's display name from the session's title instead of a random slug, and keep it in sync afterwards.
3. Let the device that displays a bridged session rename it locally, and have that rename stick.

Option 2 alone would cover most of it: the auto-generated title is usually descriptive enough, and it already exists at creation time.

### Alternative Solutions

I tried to work around it with hooks and could not:

- A `SessionStart` hook that injects context asking for a `(prefix)` in the title does not influence the auto-generated title.
- `UserPromptSubmit` cannot modify the submitted prompt text - the documented output fields are `additionalContext`, `blockReason` and `systemMessage` - so a marker cannot be placed into the text the title is derived from.
- Renaming through `set_session_title` updates the local record only, which is the behaviour this request is about.

The workaround I settled on is a `Stop` hook on the laptop that appends title / timestamp / cwd / session id to a file on a shared folder, so that from the desktop I can look up what a given `innk-*` session actually was. It works, but it is a second list to consult alongside the real one.

Typing a marker at the start of the first message also works, since the auto-generated title is derived from it - but only when I remember to, and it does nothing for the sessions that get the `-` name.

### Priority

Critical - Blocking my work

### Feature Category

CLI commands and flags

### Use Case Example

_No response_

### Additional Context

Environment: Claude Code desktop app on Windows 11 on both machines. The laptop's hostname is `INNK`, which is where the `innk-` prefix in the generated names comes from.

Same session, seen from each side:

| desktop's session list | laptop's own record |
| --- | --- |
| `innk-adaptive-octopus` | the title I actually set (Japanese) |
| creation-time title, frozen | current title, `titleSource: tool` |

### Related issues

- #92644 - session title changes not propagating to the Android app. Same underlying gap, different client; this request is the desktop-to-desktop bridged case, and additionally covers the generated `-` name, which that issue does not mention.
- #90433 - argues the opposite direction, that titles appearing across machines on one account is a leak. I am aware this pulls against the present request. My case is two machines I own, signed into the same account, which is why I want it - so making the behaviour opt-in (a setting, or per-device) would suit me fine, rather than always-on propagation.

Start by reading how bridged session records are created and displayed, and compare them with the local record path mentioned: %APPDATA%\Claude\claude-code-sessions\\\local_.json. Also trace the ccd_session_mgmt set_session_title path and titleSource/previousTitles handling. Done means a bridged session shows the meaningful title on the paired device and renames propagate or persist as the chosen design specifies.

Rédigé par le modèle d'indexation à partir du texte de l'issue.