fix(music): don't throw "Transport not connected" while a reconnect is landing

Found live: >5min screen lock while music played, then "Transport not
connected" at the 2nd track's end (~8min in) despite the auto-reconnect
from the previous commit. Root cause: fetchTrackBlob's own
`!transport.connected` pre-flight check ran and threw before the
already-in-progress reconnect got the few seconds it needed — it never
reached _sendAndWait, which is the only place the previous fix taught the
transport to wait.

Adds transport.waitForReconnect(), factored out of _sendAndWait's existing
gate, and calls it from fetchTrackBlob before giving up. No-op when nothing
is being reconnected, so the ordinary path is unchanged.

1 files changed, 8 insertions, 1 deletions

diff --git a/packages/meshbay-hub/src/meshbay_hub/static/music-player.js b/packages/meshbay-hub/src/meshbay_hub/static/music-player.js
index 7a3978c..73cae27 100644
--- a/packages/meshbay-hub/src/meshbay_hub/static/music-player.js
+++ b/packages/meshbay-hub/src/meshbay_hub/static/music-player.js
@@ -218,7 +218,14 @@ function MusicPlayerBar({ transportRef, gekRef, queue, onClose }) {
     const cached = blobCacheRef.current.get(entry.id);
     if (cached) return cached.url;
     const transport = transportRef.current;
-    if (!transport || !transport.connected) throw new Error(t('music.err_transport'));
+    if (!transport) throw new Error(t('music.err_transport'));
+    // A track ending (or "next") right after a screen-lock reconnect started
+    // is exactly when this used to throw: `connected` was still false because
+    // the reconnect it only had to wait a few seconds for hadn't landed yet.
+    // waitForReconnect is a no-op when nothing is in flight, so this costs
+    // nothing on the ordinary path.
+    if (!transport.connected) await transport.waitForReconnect();
+    if (!transport.connected) throw new Error(t('music.err_transport'));
 
     let downloadId = entry.id;
     let downloadSize = entry.size;