Merge origin/main into the chat encryption work

Both sides landed a breaking MNP change and both called it 2.0, which is right:
the sealed upload, the removal of `stream_seg` and mandatory chat encryption
share one flag day. They are recorded as one version in `__init__.py` rather
than as a race between two.

The resolutions that were decisions rather than mechanics:

* **`MNP_MIN_SUPPORTED` moves to "2.0".** The sealed upload alone was a
  *confined* break — a 1.x peer could still connect, browse, download, stream
  and chat, with only its uploads refused by `upload_not_sealed` — so the floor
  deliberately stayed at "1.0". Mandatory chat encryption ends that
  confinement: a 1.x peer can neither produce a sealed chat message nor read
  one, so it would connect, look fine, and be unable to say anything. Refusing
  it at the handshake is the honest form. The per-message `upload_not_sealed`
  path is untouched and still right if the floor is ever lowered.
* **`sendChat` throws on an `error` reply**, from origin, applied to the sealed
  send. It matters more after this change, not less: the node now refuses a
  stale epoch, a malformed envelope and a device claim that is not the
  connection's own, so there are three new ways for a message to be rejected
  and none of them may look like a message that was sent.
* **`req_id` supersedes the per-type routing** this branch added for
  `chat_keys_resp` and `device_hello_ack`. Both blocks are kept beside the
  existing `chat_hist_resp` one, for the same stated reason — a node too old to
  stamp — and their comments no longer claim to be the mechanism that closes
  the class. `req_id` is.
* **`chat_send_probe.py` is rebuilt on origin's structure**, not beside it: two
  scenarios, a stub that stamps `req_id`, `music_meta_req` as the older pending
  request. The encrypted path is layered on — a real Ed25519 device key
  generated in the page, and a `chat_keys_resp` sealed by the shipped Python,
  because a payload the page built itself would prove only that the page agrees
  with the page.
* **`test_reply_correlation.py` now sends a sealed message.** Its subject is
  which of the two messages leaving that handler carries the id; plaintext chat
  was only the fixture, and the node refuses one now.
* `groupbox` keeps both new purposes (`upload`, `chat_keys`); `protocol.py`
  keeps origin's removal of `STREAM_SEGMENT` and this branch's correction of
  the "Double Ratchet message" comment on `CHAT_MESSAGE`, which was wrong when
  it was written and is wrong differently now.

Full suite on the merged tree: 1993 passed, 11 failed — the same 11 that fail
on a pristine checkout (2 Windows service tests, 1 apps-enabled policy, 7
transcode tests that pass in isolation, and the WebRTC invite test that hangs
on its own).

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

1 files changed, 165 insertions, 0 deletions

diff --git a/packages/meshbay-node/tests/test_reply_correlation.py b/packages/meshbay-node/tests/test_reply_correlation.py
new file mode 100644
index 0000000..bfb336e
--- /dev/null
+++ b/packages/meshbay-node/tests/test_reply_correlation.py
@@ -0,0 +1,165 @@
+"""
+A reply names the request it answers.
+
+MNP carried no correlation id until 2026-09-07. A reply named its own type and
+nothing else, so a client with more than one request outstanding had to work out
+which one a message answered from the message itself — and for the replies that
+name nothing, it could not. This module sends `{"type": "error"}` from 240
+places and two of them say what they are about; `_dispatch_message`'s catch-all
+is one of the 238. Such a refusal reached no caller at all: the browser handed
+it to whichever request happened to be waiting, and the request it belonged to
+sat until its own 30s timeout. Live symptom (2026-09-06): the Chat composer is
+disabled while a send is in flight, so a chat message whose refusal went astray
+froze the tab for thirty seconds.
+
+`req_id` is the client's own pending-map key, put on the wire and stamped back
+onto the reply by `_send`. What matters here, and what the browser cannot check
+for itself:
+
+  * a reply carries it, including the refusals that name nothing else;
+  * a *broadcast* does not — it answers no request, and stamping it would hand
+    another peer's client a reply to a request it never made;
+  * work handed to a background task still answers under the right id, which is
+    why this is a ContextVar and not an attribute on the session.
+"""
+import asyncio
+import base64
+
+import msgpack
+import pytest
+from meshbay_common.protocol import MNP
+from meshbay_node.transport.webrtc_server import WebRTCPeerSession
+
+pytestmark = pytest.mark.asyncio
+
+# A device key's raw bytes. Only its length and its identity with the
+# connection's own pin matter here; nothing verifies a signature over it.
+_DEVICE = b"\x07" * 32
+
+
+class _Channel:
+    readyState = "open"
+
+    def __init__(self):
+        self.sent = []
+
+    def send(self, framed):
+        # Skip the 4-byte length prefix _pack writes.
+        self.sent.append(msgpack.unpackb(framed[4:], raw=False))
+
+
+def _session(peer_id="p"):
+    s = WebRTCPeerSession.__new__(WebRTCPeerSession)
+    s._ctx = {}
+    s._peer_id = peer_id
+    s._user_id = None
+    s._group_id = ""
+    s._channel = _Channel()
+    s._tasks = set()
+    return s
+
+
+async def test_a_refusal_that_names_nothing_else_names_the_request():
+    """The reply at the root of the defect: no type of its own to match on."""
+    s = _session()
+    # No handshake yet, so any other message is refused — a bare `error`, the
+    # same shape the catch-all sends and the same shape a browser could not
+    # route.
+    s._handle_message({"type": MNP.CHAT_MESSAGE, "req_id": 41})
+
+    (reply,) = s._channel.sent
+    assert reply["type"] == "error"
+    assert reply["req_id"] == 41, (
+        "a refusal that names neither the request nor a type of its own is a "
+        "reply no caller can claim")
+
+
+async def test_the_catch_all_refusal_names_the_request_too():
+    """Every failure in the dispatch loop funnels into one generic reply."""
+    s = _session()
+    s._user_id = "u"
+
+    def _boom(msg):
+        raise RuntimeError("filesystem path that must not reach the peer")
+    s._do_chat_message = _boom
+
+    s._handle_message({"type": MNP.CHAT_MESSAGE, "req_id": 7})
+
+    (reply,) = s._channel.sent
+    assert reply == {"type": "error", "detail": "Request failed", "req_id": 7}, (
+        "the catch-all is where an unforeseen failure ends up, so it is exactly "
+        "the reply that must still be routable")
+
+
+async def test_a_request_without_an_id_is_answered_without_one():
+    """An older client sends none; nothing may be invented for it."""
+    s = _session()
+    s._handle_message({"type": MNP.CHAT_MESSAGE})
+
+    (reply,) = s._channel.sent
+    assert "req_id" not in reply
+
+
+async def test_a_broadcast_to_another_peer_is_not_stamped():
+    """The reply goes to the asker; the broadcast goes to everyone else.
+
+    They travel out of the same handler, and only the first answers anything.
+    Stamping the second would hand another browser a reply keyed to a pending
+    request of its own that it never sent — the very confusion this fixes.
+    """
+    asker, other = _session("asker"), _session("other")
+    asker._user_id, other._user_id = "a", "b"
+    registry = {"ka": asker, "kb": other}
+    asker._peer_registry = lambda: registry
+    asker._user_names = lambda: {}
+    asker._audit = lambda *a, **k: None
+    asker._group_ctx = lambda: {}
+    asker._spawn = lambda coro: coro.close()
+
+    asker._registry_key, other._registry_key = "ka", "kb"
+    asker._pinned_pk = base64.b64encode(_DEVICE).decode()
+    asker._device_confirmed = True
+
+    # A sealed message, because MNP 2.0 has no plaintext chat and the node
+    # refuses one — the bytes need not decrypt, since nothing here opens them.
+    # What this test is about is unchanged: which of the two messages leaving
+    # this handler carries the id.
+    asker._handle_message({
+        "type": MNP.CHAT_MESSAGE, "req_id": 3,
+        "format": 1, "epoch": 1, "device": _DEVICE, "ct": b"ciphertext",
+        "nonce": b"\x02" * 12, "sig": b"\x03" * 64,
+    })
+
+    (ack,) = asker._channel.sent
+    assert ack["type"] == "ack" and ack["req_id"] == 3
+    (broadcast,) = other._channel.sent
+    assert broadcast["type"] == MNP.CHAT_MESSAGE
+    assert "req_id" not in broadcast, (
+        "a broadcast answers no request and must not look like a reply")
+
+
+async def test_work_handed_to_a_task_still_answers_under_the_right_id():
+    """Most handlers `_spawn` their real work, and the reply leaves long after
+    the dispatch call that started it has returned.
+
+    This is the reason the id lives in a ContextVar: asyncio copies the current
+    context into a task, so the answer keeps the id even though nothing passed
+    it along. An attribute on the session would have been overwritten by the
+    next message to arrive in the meantime.
+    """
+    s = _session()
+    s._user_id = "u"
+
+    async def _late(reply):
+        await asyncio.sleep(0.01)
+        s._send({"type": "roster_read_resp", "detail": reply})
+    s._do_chat_message = lambda msg: s._spawn(_late(msg["payload"]))
+
+    s._handle_message({"type": MNP.CHAT_MESSAGE, "payload": "first", "req_id": 11})
+    # A second request arrives while the first one's task is still asleep.
+    s._handle_message({"type": MNP.CHAT_MESSAGE, "payload": "second", "req_id": 12})
+    await asyncio.gather(*list(s._tasks))
+
+    by_id = {m["req_id"]: m["detail"] for m in s._channel.sent}
+    assert by_id == {11: "first", 12: "second"}, (
+        "a late reply answered under whichever request arrived most recently")