Handle bad network better

A while ago a customer was having issues with their network and it was not obvious enough in the console that these errors were not coming from our API. In traditional multi-page apps, this is not an issue because when you navigate or post a form, if the request doesn't go through, the browser will blow up and show you a "server could not be found" pageor whatever. In an SPA, we're catching errors ourselves and showing generic error page (on navigation) or displaying the error in a box (on form submit), so they're showing up "inside" the app, so unless you say otherwise, it feels like the error is coming from the app.

• Navigation: change loaders to use fetchQuery instead of prefetchQuery so it can blow up while loading rather than after, and then we have a choice about how to blow up. If we show some kind of modal without going to a full error screen, it can be less jarring and maybe give the user a chance to try again.
• Form submits: we already show errors inline in the form, but we need to detect network errors and make clear that it's not an API error.

Unfortunately I think different browsers represent network errors differently, and it's hard to reproduce bad network conditions locally — for example, the browser treats turning off wi-fi quite differently from real traffic that's messed up.

Start by tracing the navigation loaders that use prefetchQuery and the form-submit error handling described in the issue. Compare how fetchQuery changes navigation failures and how network errors appear across browsers. Done means network failures are distinguishable from API errors in both navigation and form submissions, with an appropriate retry or error-screen behavior established.