fix: OIDC/SSO Token + Media issues

[Just-Insane]

Description

Three related bug fixes for media reliability.

1. Suppress unhandled promise rejections from useAsyncCallback

useAsyncCallback stored errors in AsyncStatus.Error state and then re-threw them. Fire-and-forget call sites (e.g. loadSrc() / loadThumbSrc()) had no .catch(), so every failure produced an "Uncaught (in promise)" console error — most visibly "Mismatched SHA-256 digest" from encrypted media decryption. The error is already surfaced via retry UI; the re-throw added nothing. Removed it and updated the test accordingly.

2. Wire OIDC token refresh through to the service worker

loginUtil.ts silently discarded refresh_token from the login response, so createClient was never given a tokenRefreshFunction. After an access token expired the SDK would stall and the service worker — which caches the token for authenticated media requests — would keep sending the old Bearer token, causing 401s on every media load.

• loginUtil.ts: capture refresh_token / expires_in_ms into the session object
• initMatrix.ts: when a refreshToken is present, pass tokenRefreshFunction to createClient; the function calls mx.refreshToken() and invokes an optional onTokenRefresh callback
• ClientRoot.tsx: supply the callback; it writes the new tokens to sessionsAtom and calls pushSessionToSW so the SW picks them up immediately

No-op when the server doesn't return a refresh token.

3. Retry authenticated media requests on 401 in the service worker

There is a timing window between when the SDK resolves a token refresh (and updates its own in-flight requests) and when the resulting pushSessionToSW setSession postMessage is processed by the SW. Media requests that land in this window carry the stale Bearer token and receive 401. Because browsers retry failed image/video loads automatically, this produced repeated 401 bursts for the same media IDs.

Added fetchMediaWithRetry() in sw.ts: on a 401 response it re-checks the in-memory sessions map (and preloadedSession fallback) for a fresher token for the same origin. If one is found, the request is retried once. Applied consistently across all four code paths in the fetch event handler. Zero overhead for non-401 responses.

Fixes #

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

AI disclosure:

• Partially AI assisted (clarify which code was AI assisted and briefly explain what it does).
• Fully AI generated (explain what all the generated code does in moderate detail).

Fix 1 removes throw e from useAsyncCallback's catch block and drops the now-unnecessary .catch(() => {}) in the test. Fix 2 reads refresh_token/expires_in_ms from the login response and stores them in the session; buildClient spreads { refreshToken, tokenRefreshFunction } into createClient options when a refresh token is present; the onTokenRefresh callback in ClientRoot updates sessionsAtom and calls pushSessionToSW with the new access token. Fix 3 adds fetchMediaWithRetry() to sw.ts — a thin wrapper around fetch() that on HTTP 401 re-checks the in-memory sessions map for a token that differs from the one just used, and if found retries the request once; covers the race window between SDK token refresh and SW setSession propagation.