Strip token query parameter from SW navigation requests

[maraf]

Production reported a recurring service worker error when users land on the app via a token-bearing URL:

The FetchEvent for "https://recollections.app/?token=demo" resulted in a network error response: the promise was rejected.

Why

onFetch in service-worker.published.js forwarded the raw navigation request (including ?token=...) both to cache.match and to the fetch() network fallback. When the cache miss happened and the network fetch then failed for any reason, the promise returned to respondWith() rejected, surfacing the error above to users.

What changed

Added stripTokenFromNavigation(), called from onFetch for mode === 'navigate' requests. It rebuilds the Request without the token query parameter before the cache lookup and the network fallback. Non-navigation requests are passed through untouched.

The SPA still reads window.location.search after boot (UserState.OnInitializedAsync), so the token remains available for the LoginWithTokenAsync API exchange. Only the SW-side fetch sees the cleaned URL.

Notes

• Only the published service worker needed the change; the dev service-worker.js does not call respondWith() on regular fetches.
• No equivalent issue is filed; this is a follow-up to a production console report.

[Copilot]

Pull request overview

This PR addresses a production service worker fetch error triggered when users open the app with a token-bearing navigation URL (e.g., /?token=...). It updates the published service worker to sanitize navigation requests by removing the token query parameter before cache lookup and network fallback, reducing the likelihood of respondWith() surfacing rejected fetch promises to end users.

Changes:

• Added stripTokenFromNavigation() to remove the token query parameter from navigation requests.
• Updated onFetch to use the sanitized request for cache matching and network fallback.