fix: decode base64-serialized fetch bodies before caching them for client-side replay

[agafonovim]

When a universal load fetches a binary resource during SSR, the response is serialized into the page as <script data-sveltekit-fetched data-b64 data-ttl="..."> (data-ttl derived from the response's s-maxage/max-age, data-b64 marking a base64-encoded body).

During hydration, initial_fetch stores the entry in the client-side fetch cache before decoding the body:

const ttl = script.getAttribute('data-ttl');
if (ttl) cache.set(selector, { body, init, ttl: 1000 * Number(ttl) }); // body is still a base64 string
const b64 = script.getAttribute('data-b64');
if (b64 !== null) {
	body = base64_decode(body);
}

So the cache holds the raw base64 string. When the user client-side navigates back to the page within the TTL window, subsequent_fetch replays new Response(cached.body, cached.init) and the load function receives base64 text instead of the original bytes — e.g. an endpoint returning [1, 2, 3, 4] is replayed as [65, 81, 73, 68, 66, 65, 61, 61] (the UTF-8 bytes of "AQIDBA=="). Anything that parses the body (protobuf, images, etc.) breaks, and only on cached client-side re-navigation, which makes it look like a flaky backend.

The fix moves the decode above the cache.set so the cache stores the decoded bytes; the hydration-time Response is unaffected (it was already constructed after decoding).

Includes a regression test mirroring the existing fetch-cache-control suite: a binary endpoint with cache-control: public, max-age=7, client-side navigation away and back, asserting the byte content and that no new request was made. It fails on main with the corrupted bytes above and passes with this change; the neighbouring cache and b64 serialization tests stay green.

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 69a4624

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Rich-Harris]

thank you!

[Rich-Harris]

Please stop force pushing.

[agafonovim]

Please stop force pushing.

Sorry about that, I was updating the branch and got caught up looking into the flaky tests. I won’t force-push anymore.