Fixes #200 (dogfooding #5).

Two paired hosts echoed unchanged `channels` frames to each other forever: a peer's frame made `peers.watch` call `broadcast()`, which sent to every socket, including the inbound socket of that same peer's client. Each frame re-read the whole catalog synchronously, and every new trigger added another circulating frame, so the gateway starved over time. "Loading chat" took 20–60 s locally and remotely.

- Peer and directory changes now reach only the owner's app sockets. - Only this host's own catalog changes reach peers, as before. - Local listings are computed once per broadcast instead of once per socket.

Evidence: - **Production (natembp, Canary helper pid 64359):** gateway requests rose from ~250 ms to ~6 s over 11 minutes after the peer connected. CPU was 83–97%, with the main thread in synchronous catalog reads. One loopback socket with a single `channels` request took 9.4 s to handshake, then received 45 identical unsolicited frames in 0.6 s (~1.97 MB, ~75/s). `/health` timed out. - **Two real source hosts on this Mac, 60 channels each.** A test-only `tailscale status` shim makes this Mac list itself as a peer, so it only stands in for peer discovery. It does not validate real Tailscale discovery between two machines. `whois` authentication and all gateway traffic used the real Tailscale CLI and tailnet address: - Before: both hosts sat at ~94% CPU while idle, and one owner socket received 1,179 `channels` frames in 10 s. - After, measured at 60 s uptime: 0% CPU and 0 frames in 10 s. `/health` took 1 ms; cold channel `info` took 248 ms locally and 522 ms through the peer. - Owner listings still include both hosts. A channel created on the peer arrives as exactly one frame.

### Built in Ace

Not entirely. This Ace channel wrote the code, ran the local checks and the two-host check, wrote the issue and PR, and runs the CI and build follow-up.

Outside Ace: - **Codex** coordinated the work and reviewed the diff. Its read-only subagent audits did the source review and took the production frame and latency measurements quoted above. - **macOS Screen Sharing**, driven through Codex, installed and checked Canary on the second Mac (Nate16). Ace's desktop tools can't operate another host's desktop; that gap is #202.

Signed Canary 0.0.19 (7b55b4a, #203; build-only run 37641790495) is installed and reopened on both natembp and Nate16.

**Install** - Version confirmed on both Macs. - On Nate16, the transferred DMG matched SHA-256 `9fa18ad1a628de14f4e97f121cbac01cb9054fb79eb1b17f2f01c4eab9f033df`, and the staged app passed Gatekeeper as a notarized Developer ID build. - On both Macs, the old helpers exited normally and the new app started on the existing data. Afterwards, the installer mounts were detached and the temporary transfer server was stopped.

**natembp (source host), before → after** - Ace Helper CPU: 83–97% → 0.0%. - Loopback WebSocket connect: 9,403 ms → 11–14 ms. - `/health`: timed out at 3 s and 8 s → 0.5–5.2 ms. - Channel watch until live and transcript complete: 262 ms for modal-top-offset, 25 ms for canary-github-releases. - After the update, the resume receipt cleared and the workers resumed. - In the real app, switching to a channel showed its content immediately (within one click and a 0.5 s snapshot).

**Nate16 (viewing natembp)** - The updated app reopened, and canary-github-releases showed the full transcript from natembp. - We don't have a precise remote timing: the user went back to using Screen Sharing, so that measurement wasn't run.