Retry transient Kick playback URL fetch failures

[alembicq]

To be transparent, I've been using GPT-5.5 to debug the "This embed seems to be misconfigured" error that keeps coming up. Eventually it came up with this solution, which seems to work for me. I've been running kickstiny with this code since Friday (2026-06-12) and I haven't had any misconfigured embed errors since then, and I've seen many chatters complaining about getting it since then. The rest of this PR description is generated by GPT-5.5.

Summary

This adds a small, targeted retry wrapper around fetch() for Kick playback URL requests made by the embedded player.

The Kick embed can intermittently replace an otherwise healthy live stream with the fallback message:

This embed seems to be misconfigured

I have seen this most often after returning to a backgrounded tab. The stream is still live, and reloading the embed usually recovers it. The failures appear to come from transient network/CORS failures while refetching https://kick.com/api/v2/channels/<channel>/playback-url.

This PR retries that specific playback URL request before the failure reaches Kick's player code.

What Changed

• Adds installPlaybackFetchRetry(), which wraps window.fetch.
• Intercepts only GET requests to https://kick.com/api/v2/channels/<channel>/playback-url.
• Retries rejected fetches, which covers transient network/CORS failures.
• Also retries retryable HTTP statuses: 408, 425, 429, and 5xx.
• Uses two short retry delays: 100ms and 400ms.
• Does not retry aborted requests.
• Leaves every unrelated request untouched.
• Installs the wrapper before normal Kickstiny initialization.
• Changes the userscript from document-idle to document-start so the wrapper is installed before Kick's initial playback request and later focus-triggered refetches.
• Updates the dev userscript to work at document-start even if document.head is not available yet.
• Adds a focused Node test suite for the retry behavior.

Why This Approach

The failure is intermittent and recoverable. A later request to the same playback URL generally succeeds, so a narrow retry at the fetch boundary prevents the embed from entering its misconfigured fallback state without changing Kickstiny's controls or player behavior.

The wrapper is intentionally scoped to one endpoint and one method. It preserves the original fetch call shape for all non-playback requests, and it only retries a bounded number of times.

Testing

Automated checks run locally:

npm test
npm run build
npx prettier --check build.js dev/kickstiny-dummy.user.js package.json src/main.js src/utils/playbackFetchRetry.js test/playbackFetchRetry.test.js
git diff --check

Manual verification:

• Ran the patched userscript locally for several days.
• Did not reproduce the previous intermittent "This embed seems to be misconfigured" playback failure during that time.

Notes For Reviewers

The main tradeoff is wrapping global fetch, but the wrapper is deliberately conservative:

• Non-playback requests pass through unchanged.
• Non-GET playback requests pass through unchanged.
• Aborted requests stay aborted.
• Retry attempts are bounded to two short delays.

[freedg]

fwiw, i had gemini write a userscript earlier that does a similar thing as this pr, but in a userscript, and proxies fetches of https://kick.com/api/v2/channels/<channel>/playback-url to GM_xmlhttpRequest, which is designed to handle cross-origin shenanigans, instead of retrying the fetch. https://gist.github.com/freedg/29636a398505e3f7ff145c1ffb3bc305. I haven't had an issue since installing it this morning.

[alembicq]

I tried adding the GM_xmlhttpRequest fix as a fallback after the existing retries, if they all fail. I'm trying it now, and the code is on a new branch kick-playback-gm-fallback at dceb452.

[alembicq]

So the code in the above branch seems to work, but since it doesn't look like this will be merged, I've made a separate userscript to add the retry functionality at alembicq/kick-embed-playback-fix.