more robust recovery from manifest errors

[Rich-Harris]

follow-up to #8093:

• clears the error overlay once the error is fixed (by doing a full page reload — not sure if there's a better way?)
• removes the 'failed to update manifest' message — that's internal jargon we don't really use in a public-facing way
• removes the stack trace — it's all internal stuff that's no help to the user
• responds with an error page if the page is reloaded, instead of a) stumbling along with a stale manifest or b) in the case that the manifest was invalid from the start, failing with a cryptic internal error

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. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: 40e7824

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

[dummdidumm]

This could be more than invalid routes (matchers for example) - I chose "manifest" because it was a more generic while not being completely opaque to the user

[Rich-Harris]

I think it's still okay — matchers are part of your routes