closes #7975

This PR:

• adds a validation error that guides the user to update their Svelte version when using the CSP directive require-trusted-types-for or trusted-types.
• uses a trusted policy to register the service worker when possible
• errors if the svelte policy name is not included when trusted-types is configured
• errors if the sveltekit policy name is not included when trusted-types is configured and a service worker exists and is automatically registered by us. We don't care if the user is registering the service worker on their own because then they can create their own trusted policy while doing so

Open questions

1. Should we automatically add svelte-trusted-html to trusted-types if require-trusted-types-for is in use?
   • This will cause any other trusted type policies to throw an error.
2. Or should we only add svelte-trusted-html when the user has trusted-types configured?
   • This means any trusted type policy is permitted on the page, which kind of defeats the purpose.
3. Or should we do nothing?
   • This means any trusted type policy is permitted on the page, which kind of defeats the purpose.
   • If the user has trusted-types configured but omitted svelte-trusted-html, they will have to discover the error message in the browser console logs, and figure out that they have to add the svelte trusted type to the config themselves.
4. Or should we error when the trusted-types config option isn't configured alongside the require-trusted-types-for option?
   • This will help teach users to add svelte-trusted-html themselves.
   • Could be kind of annoying and/or limiting.

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.