[Bug]: Mobile custom network address / reverse-proxy remote access still fragile; web client Local PTYs + unavailableReason crash

### Operating system

Mobile client + browser web client (remote server access)

### Orca version

Unknown

### Details

## Summary

Separate community report from the pure “no pairing code on headless server” case: when reaching a remote Orca host **off the same LAN**, users rely on **mobile custom network address** (reverse proxy / `wss://` endpoint). That path still feels incomplete, and the **web client** surfaces hard failures after connect.

This may be the **client/UI side of remote access**, not the same bug as missing server-side pairing output — filing separately for triage. Cross-link with the headless pairing issue if investigation shows one root cause.

## Symptoms

### 1. Mobile: custom network address / reverse proxy required

Mobile UI exposes **Custom network address** for when the phone is not on the same Wi‑Fi (e.g. Tailscale hostname or static IP). Reporter notes:

- Reverse proxy is still necessary for off-LAN use
- Protocol/port customization is limited / awkward
- Example endpoint entered: `wss://www.:443`

### 2. Web client: Local PTYs unavailable

After connecting via web, UI shows:

> Local PTYs are unavailable in the web client.
> If this persists, please file an issue.

**Note:** Detailed host-ownership / local-PTY routing analysis already lives in **#9047**. Including here only as the symptom users hit on the remote-access path.

### 3. Web client console crash while showing the error

Browser console:

```
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'unavailableReason')
```

This looks like a **client-side null-safety bug** when rendering an unavailable state — separate from whether PTY routing itself is wrong.

## Expected behavior

- Off-LAN mobile access via custom `wss://` / reverse-proxied endpoint should be documented and reliable (or point clearly at official relay when available).
- Web client should not throw on `unavailableReason` when a host/PTY capability is missing.
- Errors should explain next steps (use runtime-owned workspaces, check reverse proxy WebSocket upgrade, etc.) without a console crash.

## Related

- #9047 — web client Local PTYs / host ownership on headless serve (primary for PTY routing)
- Headless pairing code / `orca://pair` connectivity (server-side reports — separate issue)
- Relay / zero-knowledge remote access feature requests (#8147, #7208, #2471)

## Possible split for maintainers

| Area | Likely owner |
| --- | --- |
| Custom network address + reverse proxy UX | Mobile transport / pairing |
| Local PTYs unavailable for server worktrees | Web client host routing (#9047) |
| `unavailableReason` TypeError | Renderer null-safety bug |