fix(check): stop rebooting the router on transient probe failures

[prorochestvo]

Closes #6

What the data showed

Analysed a read-only snapshot of the production database (2026-07-14 → 2026-08-04:
6140 runs at a 5-minute cadence, 24 735 checks). Full write-up in
the issue comment.

• 29 runs were judged "internet down" → 11 reboots executed, 4 reboot attempts failed,
  14 skipped by cooldown.
• In 28 of the 29 the raw uplink was provably alive: both ip targets connected in
  19–1118 ms, and the ping collector recorded 4/4 ICMP replies from 8.8.8.8, 1.1.1.1
  and the ISP gateway in the same runs. Only the two HTTPS domain probes failed, both
  at exactly the 5 s CHECK_TIMEOUT.
• The 29th (2026-07-31 02:55) lost every target for a single sample and healed by the
  next run; its reboot attempt failed and was not what fixed it.
• Only one pair of consecutive down runs occurred in 21 days. Every other trigger was an
  isolated 5-minute sample between healthy runs.
• A further 17 runs had exactly one domain probe time out and correctly stayed "up". At a
  ~0.6 % per-probe failure rate, independent failures would coincide ~0.2 times in 21
  days; 29 were observed, so the two probes fail from a common cause — they share one DNS
  path, in production through the very router being rebooted.

What changed

Graded verdict (domain.Verdict) — down (every ip target failed) is the only
state a reboot may follow. Every domain target failing while an ip target still
answers is degraded: recorded, announced, never rebooted. With no ip targets
configured the domain group remains the only evidence and still counts as down.

In-run confirmation — a down verdict is re-probed CHECK_CONFIRMATIONS times,
CHECK_CONFIRM_DELAY apart (persisted under a new confirm phase). One healthy sample
ends the run as unconfirmed and corrects the internet_ok written from the first
sample.

Cross-run corroboration — a reboot additionally requires the previous
REBOOT_MIN_STREAK - 1 runs to have seen the outage, via a new
RunRepository.RecentRuns. A run that falls short ends as unsustained. Fail-closed: an
unreadable history withholds the reboot.

Quieter Telegram — neither guard sends a message; the run row and a log line carry the
record. degraded and cooldown-skip notices are edge-triggered, so the five identical
cooldown notices between 01:50 and 03:05 in the issue screenshot become one.

Probe diagnostics — a failed domain probe now carries the request stage it stalled in
(stage=dns|connect|tls|request|response|body) via httptrace, so "context deadline
exceeded" stops being the end of the investigation.

New optional config (defaults shown, all clamped): CHECK_CONFIRMATIONS=2,
CHECK_CONFIRM_DELAY=20s, REBOOT_MIN_STREAK=2. Setting confirmations to 0 and the
streak to 1 restores the previous behaviour exactly.

New runs.outcome values degraded / unconfirmed / unsustained, and exit code 6
for "a failure was observed and deliberately not acted on".

Applied to the recorded history, these guards remove all 29 triggers, including the one
genuine blip that no reboot fixed.

Also in this branch

• test(httpapi): the overview-window subtest asserted a hardcoded ?since= that
  QueryService floors at now-31d; it began failing on 2026-08-01 and blocked the test
  gate. Now derived from time.Now().

Verification

go vet ./... && go test ./... green (9/9 packages). New coverage: verdict grading table,
confirmation clearing and confirming a verdict, degraded never reaching the rebooter,
streak satisfied/unsatisfied/hard-run/query-error paths, edge-triggered notices, recovery
ending on a degraded verdict, RecentRuns against :memory:, config defaults and
clamping, and the probe stage tags.

Operational follow-up (not in this PR)

The collector resolves DNS through the router itself (systemd-resolved → 192.168.1.1).
Pointing the host at upstream resolvers directly would remove the common-mode dependency
that produces these stalls at all. That is a change on the Pi, outside this repository.

🤖 Generated with Claude Code