[BUG] Forked sessions never become Remote Control eligible, so they never appear in the mobile Code tab

### Environment
- Claude desktop app 1.52386.6 on macOS 26.6.2 (Darwin 25.6, Apple Silicon), Claude Code CLI 2.1.266
- Claude mobile app, same account, Code tab

### What happens
A session created by **forking** an existing session is never registered with the Remote Control bridge, so it never appears in the Code tab of the mobile app — no matter how recently it ran, whether it is pinned, or whether its host machine is online. There is no error and no UI hint anywhere; the session is simply absent from the list.

Every visible signal points the other way, which makes this expensive to diagnose: in my case a session that had run seconds earlier, on an online laptop, pinned, with filters cleared, was missing, while a session whose device was **offline** was listed.

### Why
`remoteControlAutoEligible` is only ever assigned on a session's first turn:

```js
finishInitialEnqueue(e,t,n,r){ … r && (e.remoteControlAutoEligible = !0);
this.maybeAutoEnableRemoteControl(e, n, r ? "first_turn" : "cold_resume") }
```

and the auto-enable policy gates on that flag:

```js
remoteControlPolicyCovers(e){ return !!e.remoteControlAutoEligible && !e.scheduledTaskId }
```

A fork adopts an existing transcript, so it takes the resume path (`cold_resume`) and the flag is never set — for the whole life of the session. Nothing in the policy references `forkedFromSessionId`, so the exclusion of forks looks incidental rather than intended, especially as neighbouring resume-like paths were given explicit re-arming:

```js
clearSession: s.remoteControlAutoEligible ??= !0 // re-armed after /clear
prewarm claim: e.remoteControlAutoEligible = !0 // then …(…, "first_turn")
```

### Data
Across all 25 sessions created on this machine since 2026-09-01 (`~/Library/Application Support/Claude/claude-code-sessions///local_*.json`):

| kind | count | `remoteControlAutoEligible` | `bridgeSessionIds` | visible on mobile |
|---|---|---|---|---|
| ordinary | 18 | true | present | yes |
| scheduled task | 2 | true | absent | no — expected, `!e.scheduledTaskId` |
| forked (`forkedFromSessionId` set) | 5 | **absent** | **absent** | **never** |

No unexplained records: every case matches the code path above.

### Steps to reproduce
1. Start an ordinary session, send a message, confirm it appears in the mobile Code tab.
2. Fork that session.
3. Use the fork so it has recent activity; optionally pin it.
4. Open the mobile Code tab with all filters cleared — the parent is listed, the fork never is.

### Expected
A fork is an ordinary local session, on the same machine, under the same account. It should be offered to the Remote Control bridge on the same terms as any other session.

### Suggested fix
Re-arm eligibility on the fork path exactly as `/clear` and prewarm-claim already do (`remoteControlAutoEligible ??= true`), rather than binding it to `isFirstTurn` only. Failing that, mark such sessions in the desktop UI as not remotely reachable, instead of silently omitting them from the mobile list.

### Workaround
Enabling Remote Control manually in the session works — the policy also honours `remoteControlUserRequested`. The session must have an active query first, otherwise it returns "Remote Control requires an active session. Send a message first."

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start by locating finishInitialEnqueue, remoteControlPolicyCovers, and the fork-session path in the Claude Code codebase. Reproduce the issue by creating and using a fork, then inspect whether remoteControlAutoEligible and bridgeSessionIds are set. Done means forked sessions become eligible and appear in the mobile Code tab without manual Remote Control activation.

Written by the indexing model from the issue text.