[AbirAbbas]

Fixes what the two-network relay test (lane L3, re-check on 72a2792e6) found on the client side. One PR, split by concern: D1, P, the continue fixes (D6, D3, D5, D7), a fix round, and the change entry.

What each defect was, and what changed

D6: the chat a person picked was not the chat that opened. A bare codeaf chat continues the newest chat another computer let go of. While that automatic move ran, every explicit Enter or confirm on Home answered a chat is already continuing here; wait for it to open, and the older chat opened. Now a confirmed different chat waits with the holder the person saw (continuing <Y> next; <X> is still on its way here). The automatic move finishes, is let go without opening (through the path a closing window uses, so a shared session is never closed), and then the picked chat is taken and opened. Confirming the arriving chat joins its move. Only a confirm abandons the automatic move; opening a card and answering "leave it there" does not. An abandoned move is bounded (2 min, then cancelled the way Escape used to). With no input, a bare start behaves as before.

D3: a false "another device" refusal, and no retry card. ErrLeaseHeld went to a footer-only path that skipped #2078's card. The likely race: after a move, the receiving computer's writer re-acquires, which raises the ownership number, and a slow relay's stale listing gives the other side a card with the old number. Now every refusal keeps the 1 retry / 2 leave it there card and the draft. A fresh reading separates the same holder reopening (the card asks again, with what it now shows) from a real different device (the real refusal, on the card). Consent still binds holder and ownership number. Reproduced with the two-home rig in TestAReturnAfterTheWriterReopensIsNotALostRace.

D5: Home gave up on a slow relay, and the first message after a move stayed unsent. Home's listing had 5 s. The send check ran its own 5 s directory read while the arriving writer was still starting, and it printed Home's timeout sentence into the chat. Now Home's listing waits up to 25 s, shows waiting for <host>; still checking at 5 s, and keeps its rows. A real outage (refused, DNS, TLS, 5xx) still shows at once and retries on the old schedule. A send right after this window's own move waits up to 30 s for its writer, off the UI loop, then sends once. Displacement or another window's hold still refuses. A send that cannot leave says <host> has not answered; your message is still in the box, press enter to send it.

D1: a directly exposed codeaf relay trusted any X-Forwarded-For. Registration and dial limits counted a caller-supplied header. Now relay.Server counts the socket peer unless it is given a policy, and --trust-proxy (default off) applies one policy to registrations, dials, the pairing mailbox and link pairing. A relay behind a proxy must now pass --trust-proxy, or all its callers share one allowance. Pairing already behaved that way without the flag. Flag help, docs/relay.md and the relay manual page say so.

P (from the Cloudflare audit): a chat this computer never held came over serial object batches. SyncEngine.Holds read the store-wide publication ledger, and new chats share one store, so every new chat looked warm and skipped its frame plan. Holds now asks about this chat (its adoption record or a recorded turn), and a return into a fresh staging folder asks about the chat's existing folder. In the fixture, a cold 2 MiB chat in a used store went from 7 object POSTs to 1 frame GET, and a warm one-file return still moves 5.9 KB. Correctness rests on the unchanged completeness loop. Known perf-only edge cases (follow-up): after a failed take whose staging was removed, the next take re-downloads frames, and chat metadata restored into an empty store reads warm (today's behaviour).

D7: slow empty-folder moves. The cause is not established. Each continue now writes one chat.log line with per-phase durations. First data, from the hand walk on a local relay with the laptop under build load: time spread across directory (0.3–7.3 s), restore (0.3–11 s) and staging (1–7 s). No fixed timer showed up; it looks disk- and relay-bound under load.

Proof

• Hand walk, D6, local relay, real binary in tmux (B bare start auto-continues X while the person picks Y on Home and confirms):
  • BEFORE (72a2792e6): Y opened 1 of 3. X opened 2 of 3 with the busy line, and X was left running on B.
  • AFTER (round 1 head): Y opened 5 of 5 with no busy line. The waiting line showed, and X was let go each time (released, not running).
  • AFTER (final head): FINAL_WALK
• New tests (each maps to a contract item in the lane's spec): FINAL_TESTS
• make test-laws: LAWS
• rd (Cloudflare dev) re-measure for D3/D5: RD

Not in this PR (follow-ups)

• Worker slowness (D2/D9): every store request on the hosted relay runs two Raft authorize passes, each a device_seen commit plus a barrier, about 2.7 s per request on the dev relay. Ranked causes and the Worker follow-ups are for the relay owners: measure one request in wrangler dev --local, drop the post-I/O device_seen commit, coalesce device_seen, and name the unavailable() branch in 503 bodies. No Worker change in this PR.
• The automatic continue declines whenever B holds an older copy: continuation needs a choice for changed path: .git/COMMIT_EDITMSG (seen in L3's runs and in this lane's first walk). .git internals probably should not count as local changes.
• The duplicate directory reads in a take (≈2 requests per move) and the P edge cases above.

Stability

Nothing changes for a person who never races a continue, never hits a slow relay, and does not run a self-hosted relay behind a proxy. No change to internal/clusterstate, wire or stored formats, relay/hosted/, or workflows. HELLO

🤖 Generated with Claude Code