Diagnostics: an incidents view in the API across errors, dead letters, failed deliveries and health

`barista errors pull` in #851 plans to group errors by fingerprint and redact them in the CLI. The Diagnostics module already fingerprints and deduplicates client errors (`BarakoCMS.Diagnostics/ClientErrorRecorder.cs:32`, `BarakoCMS.Diagnostics/ClientError.cs:17`), and barakoBrew has an errors screen over them. Dead-lettered runs (#527, #833), failed deliveries (#671) and unhealthy checks each have their own place and shape.

### Why it is too specific

Grouping and redaction done in one client only helps that client. An agency's barakoBrew screen, the VS Code status bar (#843) and a ticketing script would each regroup and re-redact, differently, and raw personal data would leave the API before it is stripped. A school IT person looking for "what is broken" would still check four places.

### The general concept

An incidents view in the API: one paged, filterable list across client errors, dead letters, failed deliveries and health, grouped by fingerprint with counts, first and last seen, tenants and releases affected, redacted on the server, and carrying the resolution fields from #790. barista, barakoBrew and VS Code read it; #851 then does triage and tickets only.

### Where it lives

Module: Diagnostics, reading the other sources through a small contract the core and modules implement, so a module that records failures can add them.

### Compatibility

New endpoint, additive. Existing Diagnostics endpoints and stored errors are unchanged. #851 is amended to call this view once it exists.

### Done when

- `GET` on the incidents view returns groups from at least client errors, dead letters and failed deliveries, paged, with a test per source.
- A Sensitive field value or a token in a recorded error does not appear in the response, with a test that fails if redaction is removed.

Found in the too specific sweep of 15 September 2026.

Start with BarakoCMS.Diagnostics/ClientErrorRecorder.cs:32 and ClientError.cs:17, then trace how the Diagnostics module represents dead letters and failed deliveries. Define the endpoint and source contract around the stated paging, grouping, filtering, resolution, and server-redaction requirements. Done means tests cover each required source and confirm sensitive values and tokens never appear in responses.

Written by the indexing model from the issue text.