fix(hub): route the chat ack to the request that asked for it

Typing a message froze the Chat tab: the composer stopped taking clicks and
keystrokes, the message never appeared, and it was there all along on the next
visit to the tab.

The node answers a chat message with a bare {"type": "ack"} -- no request id,
no type of its own -- so _dispatch had nothing to match it on and left it to
the arrival-order guess at the end of the function. That guess is wrong the
moment anything else this browser asked for is still waiting: the ack went to
*that* request, and the chat send waited out _sendAndWait's own 30s timeout.
Since the composer is disabled while a send is in flight, that reads as a
frozen tab; the node had stored the message and answered, into somebody else's
promise.

An outstanding request is the ordinary case, not a rare one. The node refuses
an unknown file_id with a bare `error`, which names no request either and so
reaches none, leaving the Videos tab's media_meta_req in _pending for the full
30s. That is the one that was live when this was found.

- `ack` is now matched by request type: chat_msg, or the keypair-bundle store
  and delete, which name themselves in `detail`. A node naming neither still
  has its reply placed rather than dropped.

Every line of chat-app.js is correct and every routed message in transport.js
is routed correctly -- the defect is in the seam, so tests/harness/
chat_send_probe.py drives the two together: the real ChatPanel over the real
MeshBayTransport, with only the DataChannel replaced by a stand-in answering
what the node answers. test_chat_send.py asserts against it, and with the fix
reverted all three of its tests fail on the three visible halves of the defect
-- the composer still disabled, the message absent, and the ack resolving the
unrelated request.

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

1 files changed, 36 insertions, 0 deletions

diff --git a/packages/meshbay-hub/src/meshbay_hub/static/transport.js b/packages/meshbay-hub/src/meshbay_hub/static/transport.js
index f7ae256..62ca2d9 100644
--- a/packages/meshbay-hub/src/meshbay_hub/static/transport.js
+++ b/packages/meshbay-hub/src/meshbay_hub/static/transport.js
@@ -2310,6 +2310,42 @@ class MeshBayTransport {
       return;
     }
 
+    // A bare `ack` answers three requests: sending a chat message, and storing
+    // or withdrawing a keypair bundle. The bundle acks name themselves in
+    // `detail`; the chat one carries nothing at all, so it was left to the
+    // arrival-order guess below — and that guess is wrong whenever anything
+    // else this browser asked for is still waiting. The ack went to *that*
+    // request, and the chat send waited out its own 30s timeout instead.
+    //
+    // What that looked like, and what this was found from: typing a message
+    // froze the Chat tab. The composer is disabled while a send is in flight,
+    // so it stopped accepting clicks and keys; the message never appeared;
+    // and it was there all along on the next visit to the tab, because the
+    // node had stored it and answered — into somebody else's promise. One
+    // unanswered request is enough, and an unanswered request is ordinary
+    // rather than exceptional: the node refuses an unknown file_id with a
+    // bare `error`, which names no request either and so reaches none, and a
+    // Videos tab that asked about a file the index no longer has leaves a
+    // `media_meta_req` sitting in `_pending` for the full 30s.
+    if (msg.type === 'ack') {
+      const named = msg.detail === 'keypair_bundle_stored' ? 'keypair_bundle_store'
+        : msg.detail === 'keypair_bundle_deleted' ? 'keypair_bundle_delete'
+        : null;
+      // Without a `detail` it is a chat ack — but a node that names neither
+      // is answering whichever of the three this browser has outstanding, so
+      // the reply is placed rather than dropped.
+      const wanted = named
+        ? [named]
+        : ['chat_msg', 'keypair_bundle_store', 'keypair_bundle_delete'];
+      for (const want of wanted) {
+        for (const [, handler] of this._pending) {
+          if (handler._reqType === want) { handler.resolve(msg); return; }
+        }
+      }
+      console.warn('[MeshBay] ack (detail=', msg.detail, ') with nothing waiting');
+      return;
+    }
+
     // Everything above is routed by something in the message. What is left is
     // matched by arrival order, which is only ever a guess — and a wrong guess
     // here hands one request's answer to another, which then waits for a reply