fix(host): stop paired hosts echoing channel listings

[iamnbutler]

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 Operate a teammate host's desktop from an Ace channel #202.

[iamnbutler]

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.