No indication when `cli_remote_control_enabled` is false — desktop setting is inert and GitHub Mobile returns a bare HTTP 422

### Describe the bug

When the signed-in account's Copilot entitlement has `cli_remote_control_enabled: false`, neither the desktop app nor GitHub Mobile indicates it. Instead the feature appears available and fails opaquely:

- **Settings → General → "New sessions remote access"** can be changed and the preference persists, but has no effect.
- Sessions are created and run normally, but availability is never published for remote control.
- Sending a message to such a session from GitHub Mobile fails with a bare **HTTP 422** and no explanation.

The result is a feature that looks configurable and simply isn't. Diagnosing this took a long investigation across the app database, the app log, and the shipped binary before `/copilot_internal/user` revealed the cause was an account entitlement rather than a misconfiguration or a local fault.

### Affected version

GitHub Copilot desktop app 1.1.6 (macOS, Apple Silicon); Copilot CLI 1.0.79-5; GitHub Mobile on iOS.

### Steps to reproduce the behavior

1. Sign in to the desktop app with an account whose `/copilot_internal/user` returns `cli_remote_control_enabled: false` — for example an enterprise seat where the policy is turned off. Note that `cli_enabled`, `chat_enabled`, `copilot_app_enabled` and `cloud_session_storage_enabled` may all be `true`.
2. Open **Settings → General** and set **New sessions remote access** to the permissive option.
3. Create a new repository-backed session and let it run.
4. On GitHub Mobile, open that session and send a message.

The mobile app returns HTTP 422. Nothing is logged on the desktop side, because the request never reaches the host.

### Expected behavior

Any one of the following would make this self-diagnosing:

1. Disable or grey out **New sessions remote access** when `cli_remote_control_enabled` is false, with a note such as "Remote access is turned off for your organization."
2. Return an actionable error to GitHub Mobile instead of a bare 422 — for example "Remote control is not enabled for your account."
3. Include a machine-readable reason in the 422 response body.

Option 1 alone would be sufficient, since it prevents the user reaching the failure state at all.

### Additional context

Evidence gathered while diagnosing, in case it helps locate the gap.

**The desktop app never checks the entitlement.** The string `copilot_internal/user` appears **0 times** in a 5.4 MB app log covering a full day of use. The app's complete outbound API surface over that period was: repository issues, PR timelines, PR comments and reviews, `copilot_internal/.../merge_status`, `alive_internal/websocket-url`, `cmc_internal/api/agents/.../automations/v2`, and telemetry. Nothing entitlement-related and nothing session-registration-related.

**Availability is never published, and nothing surfaces that.** In `~/.copilot/data.db`, across all 19 sessions created between 2026-05-28 and 2026-08-08, the columns `remote_availability`, `remote_prompt_delivery`, `remote_create_state` and `remote_connect_target` have been NULL 100% of the time, and `remote_availability_revision` has never held any value other than 0. That is consistent with the client correctly declining to publish for an unentitled account — the issue is purely that the decision is invisible.

**The stored preference is honoured locally, then ignored.** `app_state.remote-session-default` reads `{"state":{"defaultRemoteSessionMode":"on","hasUserSetPreference":true},"version":1}`, and newly created sessions carry `remote_session_mode = 'on'` with `remote_control_enabled = 1` at both session and project level. So the setting writes through correctly and then silently does nothing, which strongly implies a local misconfiguration to anyone debugging it.

**Failures leave no local trace at all.** No genuine HTTP 422 is ever logged on the desktop side, and the app holds only two established outbound connections to GitHub — the REST endpoint and the Alive socket, the latter carrying only PR resource snapshots. There is no local signal a user could use to work out what happened.

**What continues to work is what made this confusing.** Plain non-repository chats work from mobile, and cloud sessions work from mobile. Both are consistent with `chat_enabled: true` and `cloud_session_storage_enabled: true` while only `cli_remote_control_enabled` is false — but from the user's side it just looks like "some sessions work from my phone and some return 422."

Related: #2751 notes that `/remote` cannot be invoked at all unless an admin has enabled remote access, so the CLI does gate on this. The desktop app and mobile app appear not to.

Happy to supply further detail from the app database or log if useful.

Start by tracing the /copilot_internal/user entitlement response and the remote-session registration path, using the described app log and ~/.copilot/data.db evidence. Compare behavior when cli_remote_control_enabled is false, then verify that the desktop setting or the mobile-facing HTTP 422 exposes an actionable explanation.

Escrito por el modelo de indexación a partir del texto del issue.