Merge branch 'debug/webrtc-lock-resume'

WebRTC transport dies silently after an extended mobile screen lock
(confirmed live via client-side trace + node logs): ICE goes
disconnected -> failed within ~10s of each other on both ends, but the
DataChannel's readyState stays "open" throughout, so nothing failed fast —
every request just sat out its own timeout, matching the reported symptom
(poster spinners, blocked chat, dead new streams, stuck music).

- Automatic reconnect on WebRTC "failed": capped exponential backoff,
  redoes the full signaling handshake, wakes immediately on
  visibilitychange instead of waiting out a throttled backoff timer.
- Fixed two real bugs the reconnect work exposed: the signaling POST to
  the hub kept using the token captured at construction, never the fresh
  one fetched per reconnect attempt (401 loop, no possible recovery); and
  connect() re-armed a diagnostic listener/interval on every attempt
  without disposing of the previous one.
- pipelinedDownload retries a lost chunk instead of aborting the whole
  transfer — covers Files downloads, video poster/thumbnail fetches, and
  music-player.js's blob-based track download.
- music-player.js: don't throw "Transport not connected" while a
  reconnect is already landing (waitForReconnect); prefetch depth now
  adapts to network type (5 tracks ahead on Wi-Fi, 3 on cellular or
  unrecognized — Firefox/Safari included, where the detection API is
  simply absent).
- video-player.js: onReconnected reissues the existing seek-to-current-time
  path, so a mid-stream reconnect looks like an ordinary seek rather than
  a dead player; holds a Screen Wake Lock unconditionally while open.
- New opt-in (off by default) user preference: keep the screen on during
  audio playback, for whoever wants to trade battery for sidestepping the
  screen-lock gap entirely — off by default because the ordinary
  expectation (matching Spotify/Deezer) is that the phone locks on its
  own while listening.
- hub: /app and / now serve Cache-Control: no-store — the SPA shell had no
  cache header at all, so a browser that cached it heuristically could
  keep re-serving an old build (old ASSET_V, old JS) through any number of
  reloads or pull-to-refreshes.

Verified against real production use across many rounds (demo groups,
actual mobile screen-lock testing) rather than synthetic reproduction
alone. 430 hub tests + 650 node tests passing throughout.

1 files changed, 6 insertions, 1 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..470f169 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,
@@ -647,7 +652,7 @@ function GroupPage({ groupId, group, token, username, userId, userPrefs,
             bar's own unmount cleanup is what actually stops playback. */
         musicQueue && html`
         <${MusicPlayerBar} transportRef=${transportRef} gekRef=${gekRef} queue=${musicQueue}
-          onClose=${() => setMusicQueue(null)} />
+          userPrefs=${userPrefs} onClose=${() => setMusicQueue(null)} />
       `}
     </div>
   `;