PushNotification reports "Remote Control inactive" (no_transport) in sessions served by `claude remote-control`

## Summary

In a session served by `claude remote-control` (server mode), the `PushNotification` tool always returns **"Mobile push not sent (Remote Control inactive)"** (`disabledReason: no_transport`), even though the session is connected from the Claude mobile app / claude.ai and permission prompts are forwarded normally. The same tool pushes fine from an interactive session started with `claude --remote-control`.

## Environment

- Claude Code 2.1.263 (native installer), Linux (Ubuntu) and macOS; reproduced on 2.1.250–2.1.263
- Started with `claude remote-control --permission-mode auto --name ` inside tmux
- `~/.claude/settings.json`: `"agentPushNotifEnabled": true`, `"inputNeededNotifEnabled": true`
- Mobile app installed and signed in with the same account

## Steps to reproduce

1. `claude remote-control --name test`
2. Open the session from the Claude mobile app and send: `notify me on my phone with a push notification`
3. The model calls `PushNotification`; the tool result is `Mobile push not sent (Remote Control inactive)`.

Expected: the push is sent (the docs say "When Remote Control is active, Claude can send push notifications to your phone", and server mode is the documented way to run long-lived RC sessions).

## What seems to happen

Server mode spawns one child per session (`claude --print --sdk-url … --input-format stream-json`, `CLAUDE_CODE_ENVIRONMENT_KIND=bridge`). The tool decides it has a push transport only when `CLAUDE_CODE_REMOTE` is set, the workspace is marked remote, or the REPL-bridge-active flag is set — and that flag is only set by the interactive `remote_control` control-request path (`/remote-control`, `--remote-control`). A bridge-spawned child never sets it, so the tool short-circuits with `no_transport` before anything is sent. Elsewhere the surface detection already treats `CLAUDE_CODE_ENVIRONMENT_KIND === "bridge"` as equivalent to the bridge being active, so the push tool looks like the odd one out.

This is not the presence check: the tool returns `no_transport` before anything reaches the server, and the same server-mode session does deliver "Claude needs your permission" and "Claude has a question" (`AskUserQuestion`) pushes to the phone — so the account, device registration and server-side preferences are all fine. Only the proactive `PushNotification` path is dead.

## Suggested fix

Treat `CLAUDE_CODE_ENVIRONMENT_KIND=bridge` (or the presence of `--sdk-url` under the server) as an available transport in the push tool, or have the server set the bridge-active state in the child.

## Workaround

Run the one session that needs proactive pushes as `claude --remote-control ` in tmux instead of server mode.

Start by tracing the PushNotification transport check and the server-mode child launch described in the report, then reproduce with `claude remote-control` and a mobile session. Compare that path with `claude --remote-control`, and confirm completion when proactive pushes are delivered in server mode instead of returning `no_transport`.

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