[feat] per-module behavioural baseline ("module personality")

[cofade]

Background

A single global "low activity = problem" threshold does not work. One module facing south-east is busy by 8 am; one in shade peaks at noon. Each module has its own normal — and anomaly detection without a per-module baseline is mostly false-positive noise.

Why it matters

• Makes the anomaly push (separate issue) actually trustworthy.
• Adds a small UX delight: each module gets a "personality" summary card (peak hours, weekday/weekend profile, weather preferences).
• Reuses data the per-module time-series store already holds ([arch] Per-module time-series store for activity + sensor data #110).

Proposal

1. Periodic job (daily) computes per-module baselines from the last N days of activity scores:
   • Hour-of-day × weekday median + IQR.
   • Weather-conditional activity, once [feat] external weather data integration (crowdsourced / open-data) #111 is live.
2. Baselines stored in DuckDB, refreshed daily.
3. GET /api/modules/:mac/personality returns the structured summary.
4. Module detail page renders a small "personality" card: "Peak hours 09–11, prefers 18–24 °C, weekend ≈ weekday."

Acceptance criteria

• Baseline job runs daily, idempotent
• Baselines table in DuckDB
• Contract type + API endpoint
• Personality card on the module detail page with at least: peak-hour window, weekday/weekend ratio, sample-size confidence
• Cold-start handled gracefully (< N days of data) — show "still learning"
• arc42 chapter 06 updated

Out of scope

• Acting on the baseline — anomaly push lives in its own issue.
• Cross-module comparison ("more active than 60% of other hives") — would require multi-tenant, out of scope per arc42 chapter 1.

Related: #110, #111