[BUG] /remote-control is unregistered (reports "unknown command") instead of naming the reason it is unavailable

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

Remote Control has several independent availability gates. Two of them produce a clear, actionable message. Two others unregister the slash command entirely, so it reports `unknown command` — indistinguishable from the feature not existing, or from me misremembering the name.

A human-readable reason string already exists in the code for every one of these cases. It just isn't reached when the command is hidden.

Four ways Remote Control can be unavailable, two different behaviors:

| Blocker | What the user sees |
|---|---|
| Server-side org policy | "Remote Control is disabled by your organization's policy. Contact your organization admin for access." — clear |
| Managed setting `disableRemoteControl` | Message naming the setting explicitly — clear |
| Custom `ANTHROPIC_BASE_URL` | **`unknown command`** |
| Feature-flag rollout (`not_in_rollout`) | **`unknown command`** |

### What Should Happen?

Keep the command registered whenever the feature exists in the build, and have it print the reason instead of being hidden. For the custom-endpoint case, something like:

> Remote Control requires a direct connection to api.anthropic.com and is unavailable because ANTHROPIC_BASE_URL points at a custom endpoint.

The reason-computing function is already there and already covers every case — custom endpoint, cloud session, managed setting, subscription requirement, not-in-rollout. Hiding the command is what discards it.

Two smaller follow-ons:

- Have `/status` or `/doctor` state Remote Control availability and the reason, next to where `/status` already reports the custom endpoint.
- Close the asymmetry with the launch flag, which does surface a reason where the slash command doesn't (see #72749, which shows `claude remote-control` printing "Remote Control is only available when using Claude via api.anthropic.com" for the same gate that leaves the slash command unknown).

### Error Messages/Logs

```shell
> /remote-control
unknown command
```

### Steps to Reproduce

1. Sign in with a claude.ai account (mine is Enterprise).
2. Set `ANTHROPIC_BASE_URL` to any host other than `api.anthropic.com` — e.g. a corporate API gateway. Setting it in `~/.claude/settings.json` under `env` is the common enterprise arrangement.
3. Run `/remote-control`.

Actual: `unknown command`.

### Claude Model

_No response_

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

2.1.231 (Claude Code), macOS arm64, homebrew cask

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

### Why this is worse than it looks

`claude --help` lists `--remote-control [name]` and `--remote-control-session-name-prefix ` **unconditionally** — the flags are documented even when the slash command reports itself unknown. So the CLI's own help advertises a feature that the CLI then denies having. That is the whole confusion in one line.

The `/teleport` what's-new entry also says *"Run `/remote-control` to take this session with you"*; I haven't checked whether that surface is gated the same way as the command.

### No diagnostic path

`/status` does report that `ANTHROPIC_BASE_URL` points at a custom endpoint, but never connects that fact to Remote Control being unavailable, and `/doctor` doesn't mention Remote Control at all. Working out why the command didn't exist required dumping strings out of the binary — there was no user-facing way to find out.

### Orientation (minified symbols, build 2.1.231)

Offered only as a pointer into the bundle:

- `_ke(e)` — host allowlist, a single inline literal `["api.anthropic.com"]`, appearing exactly once in the binary
- `hjt()` — returns true if `ANTHROPIC_BASE_URL` is unset or passes `_ke`
- `ort()` → `Q5t()` → `OO()` — availability chain; `OO()` also depends on the `tengu_ccr_bridge` flag, default false
- the command object: `{ name: "remote-control", aliases: ["rc"], isEnabled: fbS, isHidden: !OO() }` — this is where the command disappears
- `Wxo()` — already returns the human-readable reason for each case; unreachable when hidden
- `Smn()` — returns `not_signed_in | api_key_auth | no_profile_scope | not_in_rollout`

### Related, but not duplicates

- #72749 — feature request to *allow* Remote Control behind a transparent proxy. This report is not about changing the gate, only about the gate being unexplained. It does show the launch-flag path printing a reason for the same condition.
- #81546 — docs clarification on why the eligibility restrictions exist.

Start by tracing the `remote-control` command object, its `isHidden: !OO()` gate, and the existing reason function `Wxo()` in the Claude Code bundle. Compare that slash-command path with `claude remote-control` and the existing `/status` custom-endpoint report; done means unavailable states no longer appear as `unknown command` and instead show their available reason.

Vom Indexierungsmodell aus dem Issue-Text verfasst.