[BUG] Desktop: Remote Control auto-enable only fires on a session's first turn, so the 900s idle teardown silently turns it off for good

**Claude desktop app version:** 1.32352.1.0 (Windows Store build)
**Platform:** Windows 11 Pro 26200

## Summary

In the desktop app, "Remote Control on by default" (`ccRemoteControlDefaultEnabled`) is evaluated **only on a session's first turn**. Separately, `WarmLifecycle:session` tears a session down after **900s idle**, and that teardown clears the remote-control state. Every turn after that is a resume, so auto-enable never runs again and Remote Control stays off for the life of that session.

The practical result is that Remote Control is unavailable for its primary use case: **you step away, come back later wanting to drive a session from your phone, and it has silently turned itself off — and you have to be back at the desk to turn it on again.** Sessions you are actively using keep it fine; only parked ones lose it, which is exactly backwards.

## Steps to reproduce

1. Enable Remote Control by default in settings (`preferences.ccRemoteControlDefaultEnabled: true`).
2. Start a new session. It auto-enables correctly — `[rcAutoEnable] verdict: enable=true source=explicit_pref`, then `Remote control enabled: https://claude.ai/code/session_...`.
3. Leave that session alone for 15+ minutes (trivially easy with several sessions open — any session you are not currently typing in is idle by definition).
4. `main.log` shows `[WarmLifecycle:session] Idle timeout reached, disconnecting `.
5. Return to the session and send a message. No `[rcAutoEnable]` verdict is logged, no re-enable happens. Remote Control is off and must be toggled by hand.

## Evidence

From `%APPDATA%/Claude/logs/main.log`, across 23h of continuous app uptime on one machine:

- **38** `[WarmLifecycle:session] Idle timeout reached, disconnecting` events
- **5** `[rcAutoEnable] verdict:` lines total — each one within ~3s of a session's `createdAt`, i.e. first turn only
- **0** re-evaluations after any idle teardown or any resume

Concrete case from that log:

```
11:59:44 [rcAutoEnable] verdict: enable=true source=explicit_pref
11:59:47 Remote control enabled: https://claude.ai/code/session_01BYdi...
11:59:47 [remote-control] bridge_state: connected
14:40:51 [WarmLifecycle:session] Idle timeout reached, disconnecting local_228316ae-...
(no further rcAutoEnable / remote-control lines for this session)
```

Sessions created before the current app process started have never been auto-enabled at all during that process, because every turn in them is a resume.

## Mechanism (from `app.asar`)

Auto-eligibility is set only on the non-resume path:

```js
s && (o.remoteControlAutoEligible = !0), this.maybeAutoEnableRemoteControl(...)
```

where `s` is the same not-a-resume flag feeding `{ isResume: !!d.resume || !s }`. The policy gate requires it:

```js
shouldEvaluateRemoteControlPolicy(e) {
return !!e.remoteControlAutoEligible
&& !e.remoteControlEnabled
&& !e.remoteControlUserToggled
&& !e.remoteControlAutoInFlight
}
```

The idle teardown reaches the dead-CLI cleanup (`settleBackgroundTasksForDeadCli`), which calls:

```js
clearRemoteControlState(e) {
e.remoteControlEnabled = !1,
e.remoteControlAutoEnabled = void 0,
e.remoteControlAutoSource = void 0,
e.remoteControlConnecting = void 0,
e.bridgeSessionId = ...
}
```

So the flag is cleared, and nothing re-arms it. The session idle timeout is hardcoded (`idleTimeoutMs: () => 9e5`) with no user-facing preference.

## Two related gotchas found while diagnosing

1. `bridgeSessionIds` in `claude-code-sessions/**/local_*.json` persists after the bridge is gone, so the on-disk record shows a bridge id for sessions whose Remote Control is off. It is a history of bridges created, not live state — easy to misread when debugging.
2. `!e.remoteControlUserToggled` in the gate means that manually toggling Remote Control off once permanently disqualifies that session from ever auto-enabling again, even on an otherwise-eligible first turn.

## Suggested fix

Re-evaluate the auto-enable policy when a session is re-warmed after an idle teardown, not only on the first turn — or leave the remote-control binding intact across a warm-lifecycle teardown, since the teardown is an internal resource optimization rather than a user-initiated disconnect. Either would restore the "walk away, pick it up on your phone" case.

## Related

Similar symptom, different layer: #87213 covers the **CLI** replaying a dead Remote Control binding on `--resume`. This report is the **desktop app**, where the cause is the first-turn-only auto-enable gate combined with the 900s warm-lifecycle teardown.

Start by tracing the first-turn auto-enable path and WarmLifecycle:session teardown described in app.asar, using %APPDATA%/Claude/logs/main.log to reproduce the 900s idle disconnect and resume. Done means Remote Control is re-evaluated or preserved after an idle teardown when the explicit preference remains enabled, while the reported manual-toggle behavior is not unintentionally changed.

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