fix: serialize query values seeded with .set() during SSR

[Nic-Polumeyv]

closes #16384

During SSR, calling otherQuery(arg).set(value) inside a query populates the request cache but never reaches the serialized payload, so the client refetches data the server already had. The same call during a client-initiated request is included in the endpoint response and reused without a network call.

The cause is the !event.isRemoteRequest guard in the refresh() helper. It was added in #15803 for non-enhanced form submissions, where refreshing queries is pointless because the page re-renders. At that time .set() outside a form/command threw, so the guard could not affect queries. #15991 removed that error as part of the serialization rework, which made .set() inside queries legal and serialized on the endpoint path, while the SSR render path still hit the old guard and silently dropped the registration.

The render already serializes state.remote.explicit and the client already seeds its cache from the SSR payload, so the fix narrows the guard to the case #15803 actually targeted, a form or command running outside a remote request. Non-enhanced form submissions behave as before, including the noop refresh test added in #15803.

Two side effects of the narrowed guard, both consistent with the endpoint path but worth ruling on knowingly. .set() and .refresh() called from a server or universal load during SSR now also serialize. The SSR payload gains r: true when explicit entries exist, which the client start code ignores.

Tests mirror the reporter's reproduction. A list query seeds per-item detail queries, the server test asserts the seeded values appear in the SSR HTML, and the client test asserts a client-side navigation renders the seeded value with zero remote requests.

---

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.

[pkg-svelte-dev]

Install the latest version of @sveltejs/kit from 9f76db6:

pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/9f76db683092ff9ee32ceb68926b705ca40e95d6

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/kit/pr/16428

Note

This PR is from a fork. A maintainer must approve approve each commit before it can be built and installed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 9f76db6

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	Minor

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

[elliott-with-the-longest-name-on-github]

In reviewing this I realized we weren't handling refreshes correctly in the first place: #16461