Captured browser errors stay in the CMS, where the team's error tracker cannot see them

The Diagnostics module ingests browser errors at `POST /api/client-errors`, lists them at `GET /api/client-errors`, and resolves one at `POST /api/client-errors/{id}/resolve`. That is a complete small feature and it should stay.

What it cannot do is put those errors where a team already watches for errors. A frontend team running an error tracker has two inboxes: the one their tooling alerts on, and this one, which nobody is paged by.

## Why it matters

An error inbox that has to be visited is an error inbox that is read after the incident. The Diagnostics list is the CMS admin's view of client faults; it is not on-call tooling and should not try to become it.

The wire format worth speaking is Sentry's, because it is what the SDKs already emit and what the self-hosted, permissively licensed receivers accept. GlitchTip is MIT-licensed and Sentry-API compatible, so an instance can forward to it, or a team can point their existing SDK at it directly and skip us. Both are fine outcomes; today neither is possible from here.

Sentry itself is under the FSL and not open source, which is the argument for targeting the format rather than the vendor.

## What to change

An optional forwarder in the Diagnostics module, in the shape the Umami module already established:

- an options section with an endpoint and a DSN-style key, defaulting to off, so an instance without it behaves exactly as today
- a typed `HttpClient`, not a static one
- a stub handler in `IntegrationTestFixture`, because an integration that reaches the network in tests is asserting about the internet
- forwarding is fire-and-forget: a client error report must never fail because the sink is down, and a queue of undelivered reports must not grow without bound

## What has to stay true

- Ingestion stays anonymous and stays cheap. This endpoint exists because faults happen before a session does.
- What leaves the process is the concern. A browser error message can carry a URL with a token in it, a form value, or a customer name — the same class of leak as #598 and #608. Forwarding sends that to a third system, so the redaction rules have to be settled here and written in the module README, not assumed.
- Local storage and the local list stay. This is a forwarder, not a replacement.

## Done when

- An instance can forward captured errors to a Sentry-compatible endpoint, proven against a stub in tests.
- A sink that is down, slow or wrong does not affect the ingest response.
- The README says exactly which fields leave the process.

Found while surveying adjacent open source for integration candidates.

Start in the Diagnostics module and compare its integration shape with the existing Umami module. Read IntegrationTestFixture and the module README first; settle the redaction rules and forwarding behavior before adding a stub-backed integration test. Done means optional Sentry-compatible forwarding, bounded fire-and-forget failure handling, unchanged local storage and ingestion, and README documentation of exported fields.

Written by the indexing model from the issue text.