fix(transport): auto-reconnect after WebRTC failure, without dropping in-flight streams/downloads

Confirmed live (client trace + node logs, mobile screen-lock ~5min): ICE
goes disconnected -> failed within ~10s on both ends, but the DataChannel's
readyState stays "open" throughout, so nothing failed fast — every request
just sat out its own 8s/30s timeout, matching the reported symptom (poster
spinners, blocked chat, dead new streams).

transport.js: on connectionState "failed", reject pending requests
immediately (TransportLostError) and start a self-contained reconnect loop
(capped exponential backoff, redoes the full signaling handshake — the node
already discards the old session on its own "failed"/"closed", so there is
nothing lower-level to resume). New hooks: onNeedToken (fetch a fresh JWT,
since the captured one may have expired during the outage) and
onReconnected (let a consumer resume something that was mid-flight).

file-utils.js: pipelinedDownload retries a lost chunk instead of aborting
the whole transfer — covers Files downloads, poster/thumbnail fetches, and
music-player.js's blob-based track download, all of which go through it.

video-player.js: onReconnected reissues the existing seek-to-current-time
path, which already knows how to land a new stream_init on the live
SourceBuffer without resetting playback.

Playing audio is unaffected either way — musicbay.md's design downloads a
track to a blob before playing it, so a dead transport was never a network
dependency for what is already playing.

Stays on this branch until confirmed by real-device testing.

1 files changed, 5 insertions, 0 deletions

diff --git a/packages/meshbay-hub/src/meshbay_hub/static/group-page.js b/packages/meshbay-hub/src/meshbay_hub/static/group-page.js
index cdbe612..8683a70 100644
--- a/packages/meshbay-hub/src/meshbay_hub/static/group-page.js
+++ b/packages/meshbay-hub/src/meshbay_hub/static/group-page.js
@@ -226,6 +226,11 @@ function GroupPage({ groupId, group, token, username, userId, userPrefs,
         // any other, and two sources for one address is how they drift.
         const transport = new window.MeshBayTransport(HUB, live);
         transportRef.current = transport;
+        // Consulted only by the automatic reconnect after a WebRTC failure
+        // (transport.js's _reconnectLoop) — the token captured by this
+        // connect() call can be stale by then, since the whole point is that
+        // some real time (screen lock, a dead NAT mapping) passed unnoticed.
+        transport.onNeedToken = async () => (await ensureFreshToken()) || token;
 
         const ack = await transport.connect(
           nodeId, live, groupId, null, sessionKeys, session.bundleKey, username,