Controller v0.7.2: notification preferences sync to hub

- SyncPreferences() method on Notifier: POST to hub /api/v1/preferences
- IsEnabled() getter for hub connectivity check
- settingsNotificationsHandler: sync to hub after local save (3 flash message variants)
- Startup sync: non-blocking goroutine pushes prefs to hub on boot (DB rebuild recovery)
- Updated CONTEXT.md, README.md with v0.7.2 changes

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

CONTEXT.md

@@ -7,7 +7,7 @@
 >
 > Ask Claude Code: "Please update CONTEXT.md with what we did today"
 
-Last updated: 2026-02-16 (session 23)
+Last updated: 2026-02-16 (session 24)
 
 ---
 
@@ -22,7 +22,7 @@ Last updated: 2026-02-16 (session 23)
 ## Current project state
 
 ### felhom-controller (this repo)
-- **Version:** v0.7.1
+- **Version:** v0.7.2
 - **Phase 1:** ✅ COMPLETE — Stack Manager + Deploy Flow
 - **Phase 2:** ✅ COMPLETE — Monitoring & Health (scheduler, CPU/temp, healthchecks.io pings)
 - **Phase 3:** ✅ COMPLETE — Backups (DB dumps, restic integration, manual trigger, **dedicated backup page**)
@@ -33,7 +33,36 @@ Last updated: 2026-02-16 (session 23)
 - **Running on:** demo-felhom (N100 mini PC) at 192.168.0.162:8080
 - **All Phase 1-5 features working:** deploy, start/stop/restart/update, logs, health-aware states, auth, monitoring, backups, backup detail page, system monitoring page, settings page
 
-### What was just completed (2026-02-16 session 23)
+### What was just completed (2026-02-16 session 24)
+- **v0.7.2 — Fix Notification Preferences Sync (Controller → Hub):**
+  - **Two repos changed** (deploy-felhom-compose + felhom.eu):
+  - **Hub: `POST /api/v1/preferences` endpoint** (`hub/internal/api/handler.go`):
+    - New route in API handler: same Bearer token auth as /report and /notify
+    - Accepts JSON payload: `{customer_id, email, enabled_events}`
+    - Calls existing `store.SaveNotificationPrefs()` — no store changes needed
+    - Logs preference updates at INFO level
+  - **Hub: Notification section on customer detail page** (`hub/internal/web/`, `hub/internal/store/store.go`):
+    - New `GetRecentNotifications()` store method returns last N notification_log entries
+    - `handleCustomerDetail()` loads NotifPrefs + RecentNotifications
+    - `joinStrings` template function added for event list display
+    - `customer.html` template: new "Notifications" section showing email, events, and last 10 notification log entries (time, event, status, message)
+  - **Controller: `SyncPreferences` method** (`internal/notify/notifier.go`):
+    - New `preferencesRequest` struct for JSON payload
+    - `SyncPreferences(email, enabledEvents)` — synchronous POST to hub `/api/v1/preferences`
+    - `IsEnabled()` getter for checking hub connectivity
+    - Hungarian error messages for user-facing feedback
+  - **Controller: Sync on settings save** (`internal/web/handlers.go`):
+    - `settingsNotificationsHandler` now calls `SyncPreferences` after saving to `settings.json`
+    - Three flash message variants: success (synced), warning (local save OK, sync failed), error (save failed)
+    - Local save always succeeds even if hub sync fails
+  - **Controller: Sync on startup** (`cmd/controller/main.go`):
+    - Non-blocking goroutine syncs preferences to hub when controller starts
+    - Only runs if hub is enabled and email is configured
+    - Handles hub DB rebuild recovery (re-populates preferences after hub redeployment)
+  - **Files changed**: hub (3 files: handler.go, store.go, server.go, customer.html), controller (3 files: notifier.go, handlers.go, main.go)
+  - **Documentation**: README.md updated (version, notify module, phase checklist), CONTEXT.md updated
+
+### What was previously completed (2026-02-16 session 23)
 - **v0.7.1 — Phase 2: Monitoring Warnings, Dashboard Alerts & Notification System:**
   - **Three workstreams across two repos** (deploy-felhom-compose + felhom.eu):
   - **Monitoring page "Távoli monitoring" section** (`monitoring.html`, `handlers.go`):
@@ -469,11 +498,11 @@ Last updated: 2026-02-16 (session 23)
   7. Documentation: restart vs up -d for image updates
 
 ### What's next (priorities)
-1. **Manual steps for v0.7.1** — Viktor needs to:
-   - Rebuild + redeploy felhom-hub to k3s (hub code updated with notification endpoint + Resend integration)
-   - Configure `notifications.resend_api_key` in hub.yaml
-   - Set notification email in Settings → Értesítések on demo-felhom
-   - Test notification flow end-to-end (Settings → "Teszt email küldése")
+1. **Deploy v0.7.2** — Build + deploy both hub (0.1.5) and controller (0.7.2):
+   - Hub must be deployed FIRST (controller needs /api/v1/preferences endpoint)
+   - Then build + deploy controller
+   - Test: save notification settings → hub logs "Notification preferences updated" → "Teszt email küldése" → email arrives
+   - Verify: hub customer detail page shows notification email + events + log
 2. **Test alert banners** — Configure some missing ping UUIDs or disable backup to verify yellow/red banners appear
 3. **Test backup flow** — trigger manual backup via dashboard, verify restic repo + DB dumps
 4. Add `app_info` + `optional_config` to more apps (start with Immich, Mealie, Vaultwarden)
@@ -517,6 +546,7 @@ Last updated: 2026-02-16 (session 23)
 | In-memory notification cooldowns | Per-event-type cooldown map (default 6h). Lost on restart = acceptable (better to re-notify than miss). No persistence needed |
 | Health status change detection | Only notify on degradation (ok→warn, ok→fail, warn→fail). Avoids spam on flapping. First run records baseline, doesn't notify |
 | Resend HTTP API (no SMTP) | Direct POST to api.resend.com — same pattern as website contact-mailer. Simpler than SMTP setup, good deliverability |
+| Preferences sync on save + startup | Controller pushes prefs to hub (not pull). Startup sync handles hub DB rebuild. Local save always succeeds even if sync fails |
 | Chart.js embedded locally | Customer hardware may not have internet — CDN not reliable for offline environments |
 | Metrics downsampling via SQL | Bucket-based AVG in GROUP BY keeps Chart.js responsive with up to 30 days of data |
 | 60s metrics collection interval | Good balance of resolution vs. storage — ~44K rows/month for system metrics |