Local-only sessions are auto-registered with cloud Remote Control, so a dead local process reports as computer_unreachable

Split out of anthropics/claude-code#90172, which reports eight interconnected defects arising from
one root cause: the desktop app restarts itself to apply an update and destroys the running Claude
Code sessions. That issue holds the shared context and the manual recovery addendum. This is
defect 8 of eight.

**Product:** Claude Desktop (Claude Code desktop app)
**App version:** 1.37937.3 (bundled CLI 2.1.246)
**Platform:** Windows 11 Pro 10.0.26200, x64
**Reported:** 2026-08-27

## The defect

Every local session on this machine is registered with the cloud Remote Control bridge, with no
opt-in step. All five session records carry `remoteControlAutoEligible: true` and every one was
issued a bridge session:

| Session | remoteControlAutoEligible | bridge session |
|---|---|---|
| Reconciliation bias and stale checkouts | true | `session_015SgtBq...` |
| Session resume error with popup | true | `session_01XoVjgZ...` |
| Session message popup method | true | `session_013KP2dF...` |
| CCD replacement sessions method | true | `session_01NSuuWN...` |
| Server Startup | true | `session_01AkEhFK...` |

None of these sessions ever left the machine. There is no second host anywhere in this setup. The
app enables the bridge unconditionally:

```
2026-08-27 12:04:53 [info] Enabling remote control for session local_-...
2026-08-27 12:04:57 [info] [remote-control] bridge_state: "connected"
```

Users running only local sessions may not expect each one to be registered with a cloud bridge, and
nothing in the app says it is happening.

## It is also how the wrong error message gets chosen

When the local CLI process dies, the app has no local session to route to, so it falls back to the
bridge. The bridge has one vocabulary for a host it cannot reach, so the user is told their computer
is unreachable:

> **Can't reach your computer**
> It may be asleep or offline. This session will reconnect when it's back.
> `Remote Control host unreachable (computer_unreachable)`

That message is false, and it is wrong for cases that involve no restart at all. **That half is
filed separately as #90877**, with the measurements: the machine was awake, online, and running the
very app displaying the message, and a `--bg` session that exited normally after 7.4 seconds
produces the same card.

This issue is about the registration being automatic and invisible. #90877 is about the card and the
message.

## Requested

Make Remote Control registration for purely local sessions opt-in, or at least visible.

## On the existing opt-out

`disableRemoteControl` exists as a Claude Code setting:

> "Disable Remote Control (claude.ai/code, `claude remote-control`, `--remote-control`/`--rc`, auto-start, and the in-session toggle). Typically set in managed settings."

It is all-or-nothing in the same way as `disableAutoUpdates` in defect 7 (#90873). Turning it off to
stop local sessions being cloud-registered also removes claude.ai/code entirely. There is no setting
for "local sessions stay local, remote stays available."

## The nine defects

Eight were reported together in #90172, because they come from one root cause. The
ninth was carved out of defect 8 once the evidence showed it is reachable with no
restart involved. Each is filed separately so it can be triaged and closed on its own.

| Defect | Issue | What it is |
|---|---|---|
| 1 | #90867 | The update restart kills running sessions. The relaunch restores the window, not the sessions. **Core defect.** |
| 2 | #90868 | The relaunch does not preserve `CLAUDE_CONFIG_DIR`, so sessions register into the default config directory. |
| 3 | #90869 | Every installed profile restarts at once, because their update timers stay in lockstep. |
| 4 | #90870 | The restart fires without user action, even with an update banner staged and unactioned. |
| 5 | #90871 | No update policy downloads an update and waits for the user to install it. |
| 6 | #90872 | The restart fires long before the `autoUpdaterEnforcementHours` deadline. |
| 7 | #90873 | `disableAutoUpdates` also hides Help > Check for Updates, removing the manual update path. |
| **8** | **#90874, this issue** | Local sessions are auto-registered with the cloud Remote Control bridge, with no opt-in step. |
| 9 | #90877 | A session card renders as live when no process backs it, and the failure is reported as `computer_unreachable`. Carved out of defect 8; reachable with no restart involved. |

Shared context, impact, and the manual session-recovery addendum stay on the umbrella
issue #90172. The updater mechanism underneath defects 1 to 7 is filed separately as
#86556: a staged Squirrel build is applied on any relaunch, not only on the
"Relaunch to update" consent gate.

No implementation files, tests, or entry points are named. Start with the shared context in #90172 and trace how local sessions reach the Remote Control bridge; done means purely local sessions are not registered automatically, or the registration is clearly exposed with an explicit opt-in path.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.