fix: make sure promises from fetch handle errors

[dummdidumm]

Ensures that people using fetch directly in their load functions don't run into uncaught promise errors with streaming. Also adds some docs for this case.
related to #9785

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

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

[Conduitry]

I think this sort of change to our server-side fetch function makes sense - regardless of how else we decide we want to deal with unhandled promise rejections happening in user code. We should at the very least be attempting not to cause these sorts of problems within framework code.

As I mentioned in Discord, I think what makes sense is adding an uncaughtExceptionMonitor event handler in dev only that checks for unhandledRejection errors, prints out a link to some documentation, and then lets the process crash normally unless the user has attached their own unhandledRejection handler. I don't think we can do better than that without stepping on people's toes.

[benmccann]

We could also maybe add a commented out unhandledRejection handler to hooks.js with a comment saying to uncomment it if you're using adapter-node? Or possibly we could add one automatically in the adapter-node output, but we'd have to see what happens if two are provided (e.g. maybe Sentry provides one?)