[1.x] fix: Handle network connection loss in the frontend

[gianniguida]

Problem

All frontend XHR goes through Application#request(). When a request fails at the network level — the user is offline, DNS fails, the origin is unreachable — the rejection carries status === 0, which requestErrorCatch() has no branch for. Users get the generic "Oops! Something went wrong. Please reload the page and try again." alert, which wrongly suggests a server-side bug and prompts bug reports for what is a client connectivity issue.

Core also makes no use of the browser's online/offline events, so users get no proactive indication that they've gone offline, and content that failed to load while offline stays missing until a full page reload.

This was discussed with @imorland and is contributed as three self-contained commits.

What this PR does

1. Classify network-level failures (status === 0) — requestErrorCatch now shows a dedicated translated alert: an offline-specific message when navigator.onLine === false, otherwise a generic connection-problem message. The existing cross-origin special case is preserved inside the new branch. Parallel failures produce a single alert instead of one per request. Aborted requests cannot trigger this: Mithril (2.0.4) wraps xhr.abort and leaves aborted promises unsettled, so they never reach the error handler by construction.

2. online/offline events + automatic retry — going offline shows a persistent, dismissible alert; reconnecting clears all connection alerts and shows a brief confirmation. Additionally, a GET request that fails while the browser reports being offline is not rejected: its promise is held open, and the request is re-issued when the online event fires, settling the original promise with the retry's result. Content that failed to load while offline (post stream pages, discussion lists) appears automatically on reconnection with no changes to calling code. Only GETs qualify — writes keep failing fast, so nothing can be submitted twice. A network failure while the browser reports being online still rejects exactly as before, so no promise can wait for an online event that will never come.

3. Deduplicate deferred requests — deferred requests are keyed by method + URL + params; identical requests queued while offline are retried with a single request whose result settles every caller's promise. This matters in practice: e.g. FoF Horizon's admin stats widget polls a GET every 5 seconds, which would otherwise replay dozens of identical requests on reconnection.

New locale keys: core.lib.error.network_message, core.lib.error.offline_message, core.lib.connection_restored_message (English only).

Behavior notes

• customErrorHandler and rejection propagation are unchanged for every status except the offline-GET deferral case; regression tests cover 422/500/cross-origin.
• A survey of core, bundled extensions, and popular FoF extensions found no GET call sites whose errorHandler/.catch logic would be adversely affected by deferral — GET failure handling in the wild is loading-flag resets, which now correctly keep spinners visible until the content self-heals.

Testing

• 22 new Jest unit tests (tests/unit/common/Application.test.ts): status-0 classification (online/offline/cross-origin), alert dedup, custom-error-handler contract, 422/500 regression guards, connectivity events, deferral + resolution on reconnect, re-deferral while still offline, retry dedup.
• Manual smoke test on a local 1.x forum: offline request failure → single dedicated alert; reply while offline → alert + composer content preserved; reconnect → offline alert cleared, confirmation shown, deferred content loads without reload; 422/500 render as on 1.x.

Screenshot

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

Required changes:

• Related documentation PR: (Remove if irrelevant)