Split from #447 (item 3 of 4). Eight production domains returned 5xx at the edge for ~18 hours (2026-08-05 21:10 -> 2026-08-06 15:00) without any automated signal; recovery started only when a human noticed.
hydrascalerouter already probes every published backend each poll cycle and logs DEGRADED with the unreachable domains (ProbeBackends in the serve loop), so the detection exists - it just goes nowhere. Required: when a registered domain's backend stays unreachable (or the public vhost stays 5xx) beyond a threshold, raise an alert and auto-file a hydraissue via POST /report on issues.experiencenet.com (public create form, no token needed). Include domain, backend, node/scale provenance and first-seen time. Debounce so one incident files one issue, not one per poll.
Evidence + scope note for failure adjacent to this issue: the multi-hour fleet binary-download outage (release mirror redirect pointed at a downed Pi). This mechanism (probe -> threshold -> auto-file hydraissue) is exactly what should catch it, but as written it will NOT: (1) releases.experiencenet.com is not a router-registered domain — confirmed against /routes on the district router, only hydramirror.experiencenet.com backends appear — so the router never probes it; (2) hydrarelease returns a 302 to a mirror (internal/api/server.go:217), not a 5xx, so a redirect to a dead target reads as healthy to an edge-5xx probe. App-level failover exists (commit 0afaad5) but its probe is a HEAD to the mirror base URL (mirror.go:107-118), blind to per-file availability. The missing piece is a standing synthetic GET of a known release file through releases.experiencenet.com that follows the redirect and asserts 200 + content-length. Tracked in #482 (reusing this issues alert+auto-file plumbing), alongside the hydrabackup and mesh-handshake gaps.