feat: Add a speedier script tag for prerendered redirects

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

Closes #9907.

TODO:

• I'm not sure I landed on the right solution for encoding URIs. It passes the tests... but I'm not sure that means it's good.

(I also deleted some empty +page.svelte files, which used to be required but now are not)

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:.

[changeset-bot]

🦋 Changeset detected

Latest commit: b1af08e

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

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

Looks like I missed a few tests; will have to go back and fix 'em

[Rich-Harris]

i feel good about the encoding, but this has historically been a blind spot of mine so i'd be happy to wait for others to weigh in (@Conduitry is particularly adept at heading off string encoding bugs)

[Conduitry]

Hm. What specifically are we trying to handle by doing encodeURI(decodeURIComponent(...))? I'm worried about that losing the encoding on some characters that we actually need it for.

Since " and \ and < are all encoded by encodeURI, I think we're safe from injection attacks here. But I am still worried about ending up on the wrong URL. For example, a %40 in the original URL would end up a @ in the location.href= string.

Can we instead do a straight string escaping thing of location like we do for the values that get serialized into the inline <script> tag that starts the app on regular pages? Note that this is not just JSON.stringify() because there are some additional characters that need to be escaped to be safe. Even using devalue should work if we don't have another function for this hanging around anywhere, although it would definitely be overkill. It being overkill might not matter so much, since this is done at build time anyway, not runtime.

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

Thanks @Conduitry -- the reason we were doing a decode/encode is to avoid double-encoding. That being said, I think you're right about just string-escaping it. I'm not going to have time to do this today or tomorrow, so I'll probably get it done on Monday.

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

@Conduitry -- mind taking a look now that we're using devalue.uneval?