Web board shows live but empty catalog through an SSH port forward

Odu's web UI shows **“live” and “No runs in the catalog yet” through an SSH port forward**, while opening the same server directly on localhost lists the runs. This is reproducible in two tabs of the same browser. The underlying cause is not yet established; the empty-state/healthy-status combination is misleading regardless.

### Reproduction observed on 2026-09-13

1. Odu is running on `naiveintent`, listening on `127.0.0.1:18440` (Bun PID 2477101).
2. `pureintent` exposes that listener with a plain SSH local forward:
```sh
ssh -L '*:18440:127.0.0.1:18440' naiveintent 'echo PORT-FORWARD-READY; cat'
```
`ss` confirms SSH owns pureintent's public port 18440. This is forwarding to the same service, not a separate catalog.
3. Open `http://127.0.0.1:18440/` in a browser on naiveintent: hundreds of runs appear, including run `0mu08a1p1-nctlhal2`, branch `native-stand`, commit `8ab986478`.
4. Open `http://pureintent.rooster-blues.ts.net:18440/` in another tab of that browser: header says `live`, All is selected, and the board says there are no runs. It stays empty for several minutes.

The original report was from a separate user's browser at the forwarded URL; the same-browser comparison above reproduced it independently.

### Read-only diagnostics

- The HTML fetched through both URLs is byte-identical. Forwarded HTML, JS, CSS and logo requests all return HTTP 200; browser console is empty.
- A raw browser WebSocket to the forwarded `/rpc/ws` reaches OPEN. This establishes that the handshake succeeds, not that RPC/subscriptions are healthy.
- Local `odu surface get service`, `odu surface keys runs`, and `odu surface get runs 0mu08a1p1-nctlhal2` succeed.
- `odu surface get service --origin http://pureintent.rooster-blues.ts.net:18440` failed after waiting with:
```text
RpcClientDefect: the wire re-dialled beneath this call: it was bound to socket epoch 1, the wire is now at socket epoch 2. Effect RPC registers an entry exactly once and never re-sends it onto another socket...
```
- A subsequent forwarded `odu surface get runs 0mu08a1p1-nctlhal2` reported:
```text
"runs" did not answer for key "0mu08a1p1-nctlhal2" within 5000ms — the read did not complete, so whether the item is there is still unknown
```

### Running service identity

```text
oduVersion: 0.1.0
protocolVersion: 1.3
storageVersion: 1
buildId: /nix/store/yyg5sj6gdlj4q91vxi994ha11b78sbds-odu
source: /nix/store/g4gpv9yab9906vcbqsajh5zdicq4m4cp-odu-base-0.1.0
catalog: /home/srid/.local/state/odu/runs
```

The client command was Kolu's pinned Odu (`juspay/odu` revision `6f7de52edb7f20c356a5e059031cab1955b0ca79`); the already-running service reports a null commit, so that pin should not be mistaken for the service revision.

Expected: the forwarded page displays the same catalog. If catalog delivery stalls, show loading/degraded/error state rather than a healthy, empty catalog.

Start with the web board's catalog loading and the /rpc/ws entry point, comparing direct localhost access with the forwarded URL. Reproduce the socket re-dial and RPC timeout described in the issue, then trace catalog delivery through the client. Done means the forwarded page shows the catalog, or clearly reports loading, degraded, or error state instead of a healthy empty result.

Written by the indexing model from the issue text.