Phase 9: Hub API and Apprise alerts (/capabilities, /ask, /notify)

Build on Phases 1-8. Adds the project side of the frozen Hub contract
(central_ai_llm_master/docs/ask-contract.md) and the alert engine from
AGENTS.md §4 FR-12/FR-13, §8, §11 Phase 9.

- hub: internal/hub implements AskRequest/AskResponse/NotifyRequest and a
  deterministic, read-only Answerer. It answers screen time today/yesterday,
  what is blocked now, and device presence, scoped to one child or all kids.
  Screen time is the foreground-app total per device-day; the domain total is
  used only when a device reports no apps, so a report carrying both is never
  double-counted.
- apprise: internal/apprise is a small Apprise API client (stored key or
  stateless URL mode, optional bearer token, typed notifications).
- alert: internal/alert evaluates device state on an interval and raises one
  Apprise alert per transition: a limit hit (a device becomes blocked) or a
  device offline longer than the threshold. A never-seen device is never
  alerted, and the first observation seeds state without replaying an old
  limit. The alert is recorded before delivery, with its delivery outcome.
- store: migration 005 adds `alerts` (delivery outcome, audited) and
  `alert_state` (per-device dedup). New usage reads from the telemetry detail
  table so the daily answer can be checked independently.
- web: GET /capabilities, POST /ask (read-only) and POST /notify behind the
  shared CONTROL_HUB_TOKEN, separate from the session and admin API tokens.
  /notify accepts the contract's {from,level,message,person} and delivers it
  through Apprise (the future tamper-report path, FR-17).
- cmd/control: start the alert engine (CONTROL_ALERTS_ENABLED,
  CONTROL_ALERT_OFFLINE_AFTER, CONTROL_ALERT_INTERVAL) and add `alerts` and
  `usage` subcommands for read-only inspection.
- deploy/verify-phase9.sh + `make verify-phase9` prove the definition of done;
  version 0.7.0-phase9.

Measured on .13 (2026-10-13):
- GET /capabilities -> internet_use_control topics.
- POST /ask "how long have the kids been on screens today?" -> "The kids have
  had 1h 22m of screen time today." (total_seconds=4925); the independent
  count from the telemetry detail table is also 4925 (app=4925, domain=4800).
- A manual lock raised a delivered limit alert (id 4); an MQTT offline status
  raised a delivered offline alert (id 5); POST /notify delivered (id 6). All
  three report delivered=1 in `alerts`.

Tests: gofmt, go vet ./... and go test ./... pass in golang:1.25-alpine.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

internal/store/reports.go

@@ -260,6 +260,79 @@ func (s *Store) TopUsage(ctx context.Context, id int64, from, to, kind string, l
 	return out, nil
 }
 
+// DeviceDayUsage is one device's rolled-up usage for one day. AppSeconds and
+// DomainSeconds are kept apart for the same reason as the rollup: a report may
+// carry both for one session, so adding them together would double-count time.
+// The screen-time answer decides how to combine them (internal/hub).
+type DeviceDayUsage struct {
+	DeviceID      int64
+	Name          string
+	Child         string
+	AppSeconds    int
+	DomainSeconds int
+}
+
+// UsageByDeviceForDay returns the daily rollup for every device that reported
+// anything on day (YYYY-MM-DD). It is the read the screen-time answer is built
+// from. Devices with no row are absent; the caller treats them as zero.
+func (s *Store) UsageByDeviceForDay(ctx context.Context, day string) ([]DeviceDayUsage, error) {
+	rows, err := s.db.QueryContext(ctx, `
+		SELECT d.id, d.name, d.child, td.app_seconds, td.domain_seconds
+		FROM telemetry_daily td
+		JOIN devices d ON d.id = td.device_id
+		WHERE td.day = ?
+		ORDER BY d.id`, day)
+	if err != nil {
+		return nil, fmt.Errorf("usage by device for day: %w", err)
+	}
+	defer rows.Close()
+
+	out := make([]DeviceDayUsage, 0, 8)
+	for rows.Next() {
+		var u DeviceDayUsage
+		if err := rows.Scan(&u.DeviceID, &u.Name, &u.Child, &u.AppSeconds, &u.DomainSeconds); err != nil {
+			return nil, fmt.Errorf("scan device day usage: %w", err)
+		}
+		out = append(out, u)
+	}
+	if err := rows.Err(); err != nil {
+		return nil, fmt.Errorf("usage by device for day: %w", err)
+	}
+	return out, nil
+}
+
+// DetailUsageByDeviceForDay is the same measure computed straight from the
+// telemetry detail table instead of the derived rollup. It exists so an
+// operator can independently check the rollup the daily answer reads.
+func (s *Store) DetailUsageByDeviceForDay(ctx context.Context, day string) ([]DeviceDayUsage, error) {
+	rows, err := s.db.QueryContext(ctx, `
+		SELECT d.id, d.name, d.child,
+		       COALESCE(SUM(CASE WHEN t.app <> '' THEN t.seconds END), 0),
+		       COALESCE(SUM(CASE WHEN t.domain <> '' THEN t.seconds END), 0)
+		FROM telemetry t
+		JOIN devices d ON d.id = t.device_id
+		WHERE t.day = ?
+		GROUP BY d.id
+		ORDER BY d.id`, day)
+	if err != nil {
+		return nil, fmt.Errorf("detail usage by device for day: %w", err)
+	}
+	defer rows.Close()
+
+	out := make([]DeviceDayUsage, 0, 8)
+	for rows.Next() {
+		var u DeviceDayUsage
+		if err := rows.Scan(&u.DeviceID, &u.Name, &u.Child, &u.AppSeconds, &u.DomainSeconds); err != nil {
+			return nil, fmt.Errorf("scan detail device day usage: %w", err)
+		}
+		out = append(out, u)
+	}
+	if err := rows.Err(); err != nil {
+		return nil, fmt.Errorf("detail usage by device for day: %w", err)
+	}
+	return out, nil
+}
+
 // CapAudit keeps the newest max audit rows and deletes the oldest beyond that,
 // so the append-only log cannot grow without bound (AGENTS.md §7 retention). It
 // returns how many rows it removed. Nothing in the audit log is ever edited.