fix(mnp): give a reply an id, so it stops being routed by luck

MNP carried no correlation id. A reply named its own type and nothing
else, so a client with more than one request in flight worked out which
one a message answered from the message itself — and for the replies
that name nothing it could not. `_dispatch` fell through to matching by
arrival order, which is a guess. `_sendAndWait` had the right value all
along: it keys `_pending` by `this._seqId++` and never put it on the
wire.

The guess fails asymmetrically, which is why it hid. The victim is not
the request that was answered wrongly — it is the unrelated one that now
waits out its own 30s timeout for a reply already delivered elsewhere.
Live on 2026-09-06: five `music_meta_req` sat pending for over 100
seconds behind a failing MusicBrainz, and a `device_list_result` was
handed to one of them. The composer is disabled while a send is in
flight, so a chat message whose reply went astray the same way left the
Chat tab looking frozen for thirty seconds, then unfroze on its own.

The `ack` half of this was fixed on 2026-08-30 by matching on request
type. That closed the instance and left the class open: a refusal has no
type to match on either, and `_dispatch_message`'s catch-all answers
every unforeseen failure with `{"type": "error", "detail": "Request
failed"}` — 238 of this module's 240 error sends name nothing at all.

`req_id` now rides on the request and comes back on the reply. On the
node it is published for the whole handler in a ContextVar and stamped
by `_send`: a parameter would have meant threading an argument through
all 240 send sites, and asyncio copies the context into a task, so a
handler that `_spawn`s its real work still answers under the right id.
It is never stamped on a broadcast — those answer nothing, and the
owner check in `_send` is what keeps a chat broadcast or an index push
from reaching another peer looking like a reply.

On the client, `_dispatch` resolves on `req_id` first and the
arrival-order fallback is gone the moment a node proves it stamps
(`_correlates`, armed by the handshake's own reply). The fallback stays
for an MNP 1.0 node, unchanged and no wider: there it is the only thing
there is, and removing it would leave device_list_result, join_result
and the handshake replies reaching nobody.

Two things fall out. `sendChat` refuses an `error` reply like every
other request in the file — it returned it as success, which did not
matter while a refusal reached the wrong caller anyway and would now
show a rejected message as sent. And `_group_ctx` uses `.get`: a reload
pops a removed group while sessions connected to it are open, and every
request they had left raised KeyError into that same catch-all.

Sealed index messages are the one exception to the fast path. They
cannot be handed over until they are opened, which is asynchronous while
`_dispatch` is not — resolving on the id alone gave `fetchIndex` the
envelope and skipped `onIndexSync` entirely. Caught by extending
`index_seal_probe.mjs` to stamp a reply the way a current node does,
after the hub suite passed over it: the probe built its own frames and
had never seen one.

Tests, all failing before and passing after: `test_chat_send.py` drives
the real ChatPanel over the real transport for both shapes of reply with
an older request pending (3 of its 6 are new, and the 3 for `ack` pass
either way, so it discriminates); `test_reply_correlation.py` pins the
node's half — the refusals that name nothing else, the broadcast that
must not be stamped, and a late reply from a spawned task answering
under its own id rather than the most recent request's.

Full suite: 1897 passed, same 11 pre-existing failures as before.

QUIC keeps its own dispatch and is not stamped. It is disabled by
default and no browser request reaches it, but the asymmetry is real.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Dn1xYx9uT69mCB6UDvyKAN

1 files changed, 22 insertions, 5 deletions

diff --git a/CLAUDE.md b/CLAUDE.md
index 4a4175f..04f6e61 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -471,11 +471,28 @@ anything that assumes one key per person.
   next visit to the tab, since the node had stored it and answered. Every line
   of `chat-app.js` is correct and every routed message in `transport.js` is
   routed correctly; the defect is in the seam, which is why
-  `tests/harness/chat_send_probe.py` drives the two together. `ack` is now
-  matched by request type (`chat_msg`, or the keypair-bundle store/delete that
-  name themselves in `detail`). Anything left to the "oldest pending" guess is
-  a latent version of this bug: a request type deserves a key, and a reply
-  deserves something to key it by
+  `tests/harness/chat_send_probe.py` drives the two together. `ack` was matched
+  by request type (`chat_msg`, or the keypair-bundle store/delete that name
+  themselves in `detail`), and that closed the instance — **but it left the
+  class open, and it came back on 2026-09-06 through the other door.** A
+  refusal has no type of its own to key on: `_dispatch_message`'s catch-all
+  answers every unforeseen failure with `{"type": "error", "detail": "Request
+  failed"}`, and 238 of `webrtc_server.py`'s 240 error sends name nothing
+  either. So a chat send the node refused was routed by luck all over again —
+  same frozen composer, same 30 s, and rare enough (it needs an older request
+  still waiting, which a `music_meta_req` behind a failing third-party lookup
+  supplies for over a hundred seconds) to look like once every couple of days.
+  The keys were never the fix, only a workaround for a protocol that carried no
+  correlation id at all: `_seqId` existed, indexed `_pending`, and was never put
+  on the wire. It is now (`req_id`, see `protocol.py`) — the node stamps it on
+  the reply from `_send`, via a ContextVar so a handler's spawned work still
+  answers under the right id, and never on a broadcast, which answers nothing.
+  With that, the arrival-order fallback is gone for any node that stamps.
+  The lesson is not "key the replies": it is that **matching by arrival order
+  is a guess that fails silently and asymmetrically** — the victim is never
+  the request that was answered wrongly, it is the unrelated one that now
+  waits for a reply already delivered elsewhere. A reply needs an identifier
+  the protocol guarantees, not a field it happens to have
 
 - **A refusal that never rejects.** Denying Chromium's `fullscreen` permission
   does not make `requestFullscreen()` throw — the promise never settles. The