Remote Control registration is lost after /clear and never re-established

Environment

• Claude Code 2.1.219 (desktop-bundled) / 2.1.220 (CLI), macOS (darwin-arm64)
• claude.ai Max subscription, first-party endpoint
• remoteControlAtStartup: true in ~/.claude/settings.json

Steps to reproduce

1. Set remoteControlAtStartup: true and start a session — it auto-appears in the mobile app's Remote Control list ✅
2. Run /clear in that session
3. The entry disappears from the mobile list, and the post-clear conversation is never re-registered. Only a manual /remote-control brings it back.

Expected

The session stays controllable (or re-registers) across /clear. The setting's own description says "Start Remote Control bridge automatically each session", and /clear's description says "Start a new session with empty context" — so a post-/clear session should have the bridge too.

Analysis

The auto-connect predicate (remoteControlAtStartup / --remote-control) is evaluated once during REPL bootstrap. /clear mints a new conversation id (conversation_reset) in the same process, and its handler never re-runs bridge registration — so the old bridge session is archived and the new conversation id is left unregistered. Opening a brand-new conversation works because that spawns a new process, which re-runs the startup predicate.

Impact

Users who keep long-lived named sessions and reset context with /clear silently lose mobile access every time they clear.

Related but distinct: #63924 covers /clear sent from the remote device; this issue is about local /clear destroying the registration.