device-health-oracle: detect link impairment from monitoring data

[nikw9944]

Summary of Changes

• Add bidirectional LinkHealth transitions to the device-health-oracle. The DHO previously had zero LinkCriterions configured — links auto-advanced from Pending to ReadyForService and stayed there forever, even when ISIS was down or every packet was being dropped. This PR adds the demotion path (and a slow recovery path back).
• ReadyForService → Impaired triggers on the most recent link_rollup_5m bucket (fast detection, single bucket). Impaired → ReadyForService requires every distinct bucket in the recovery window to be clean (slow recovery, anti-flap).
• Recovery window reuses the existing --drained-slot-count (~30 min default) — no new burn-in flag introduced. New --link-loss-threshold flag (default 5.0) controls the per-direction loss cutoff.
• LinkHealth is reported as a signal only; the serviceability program does not gate link.status on it.
• Fixes device-health-oracle: detect link impairment from monitoring data and update link.health #2652

Implementation notes

• Stale-data floor: a "latest" bucket older than 15 min (3× rollup cadence) is treated as no data. Without this, a frozen telemetry pipeline at the moment of an ISIS flap would keep the link Impaired forever even after the link recovered.
• Recovery query deduplicates late-arriving rows by argMax(..., ingested_at) per bucket, so a corrected re-write doesn't keep a link Impaired after every distinct bucket reads as clean.
• --link-loss-threshold is validated at startup (must be finite and in [0, 100]) — a misconfiguration would otherwise produce an onchain write storm.
• MetricCriterionResults is now incremented for link criteria too (parity with device criteria) so impairment/recovery rates are graphable.
• Backwards compatible: deployments without ClickHouse continue to behave exactly as before — no demotion, no recovery, no impairment criterion is wired up.

Testing Verification

• New unit tests cover all six transition cases (Pending/RFS/Impaired × pass/fail), the impairment-mode and recovery-mode criterion paths, the stale-bucket floor, threshold boundaries, no-data handling in both modes, ClickHouse error propagation, and the LinkBurnIn helper.
• New ClickHouse tests assert the actual SQL shape: argMax-per-bucket dedupe, provisioning = false filter, double-quoted database name, and ? bind parameters.
• Manually validated both queries against mainnet link_rollup_5m data via the DoubleZero MCP — known impaired link DzHDqj3cdi77eMLWKemdhfr6YZJeHHGxuysvAdekniC returns bad=5/total=5 over the last 30 min and the latest bucket reads isis_down=true, a_loss=100, z_loss=100, matching what the issue reports.
• make go-test, golangci-lint, and go vet all clean.