Return the latest result from each background health probe.

Probes run automatically on a schedule. The headline ones:

• api_self_check (every 5m) - calls GET /v1/company/{reference} on the public hostname, with a real API key, and requires all three of: HTTP 200, the right company in the body, and a response inside a 5-second budget. This is the only probe that asks the customer's own question. A 200 alone is not a pass: during the 2026-08-13 outage /v1/health answered 200 at 12-15 seconds while ~90% of real traffic was 499/502.

• event_loop_lag (every 60s) - measures how long the API's event loop takes to reschedule a sleeping task. The API runs a single event loop, so this delay is paid by every concurrent request, including this one. Unlike per-request duration_ms, it sees work that blocks the loop after a response is sent or inside a background job (CH-Api#110). max_lag_ms under 250 is healthy; over 1000 means requests are queueing.

• ch_api_profile (every 6h) - fetches a real company profile and verifies the response fields our code depends on are still present and correctly typed. Detects silent CH API schema changes before they break customers.

• rate_limit (every 1h) - checks the X-Ratelimit-Remain header and alerts when the budget drops below 20% of the 600-per-5-minutes allowance.

• document_api (every 12h) - fetches filing history and hits the CH Document API to confirm iXBRL downloads are still accessible.

Possible statuses:

• pass - probe succeeded with no issues
• degraded - probe completed but detected a warning condition
• fail - probe failed (connection error, unexpected HTTP status, missing fields)

Note: Results are stored in memory. After a server restart, probes run once immediately at startup and then on their normal schedule.

No authentication required. Safe to poll at low frequency (once per minute max).

Upstream usage: 0 - reads from memory only. No upstream calls made.