[feat] hive-heartbeat anomaly detection + push (extends #1)

[cofade]

Background

Issue #1 wants user notifications on critical states. The hardest part of "critical" is defining it — a hardcoded "if activity = 0 for 24 h" is naive. Combined with the per-module baseline (#115) and weather context (#111), we can detect relative anomalies and only push when something is genuinely unusual.

Why it matters

• Closes the meaningful half of User Notifications #1 in a way that does not fatigue operators.
• Catches predator/parasite events, equipment failures, and weather-independent activity collapses.
• Demonstrates the value of the architecture pieces (notifications channel [arch] notifications channel abstraction (mail / webhook / ntfy / telegram) #113 + per-module baseline [feat] per-module behavioural baseline ("module personality") #115) end to end.

Proposal

1. Daily (or hourly?) job evaluates each module against its baseline + current weather.
2. If observed activity is outside the expected band (e.g. > 2σ below predicted under similar weather) for K consecutive evaluations, raise an anomaly.
3. Anomaly fed into the notifications channel ([arch] notifications channel abstraction (mail / webhook / ntfy / telegram) #113) with module name, baseline value, observed value, and suggested causes ("possible predator activity", "possible network issue if no images uploaded").
4. Operator can mark anomalies as resolved / false positive — feedback loops into baseline confidence.

Acceptance criteria

• Anomaly detector implemented + unit-tested with synthetic time series
• Anomalies stored with classification (activity_drop, no_uploads, battery_low_combined)
• Push delivered via the notifications channel
• Operator UI: anomaly inbox per module with resolve / dismiss actions
• Dedup window honoured — one anomaly does not generate three pushes
• arc42 chapter 06 updated; ADR for the detection approach
• Addresses User Notifications #1; references [arch] notifications channel abstraction (mail / webhook / ntfy / telegram) #113 (notifications) and [feat] per-module behavioural baseline ("module personality") #115 (baseline)

Out of scope

• Specific predator/parasite identification (separate ML problem).
• Operator-configurable thresholds — v1 ships sensible defaults.

Related: #1, #110, #111, #113, #115