Smoke-test the daily-UTC-time auto-fetch schedule (v0.10.0)

[rtanglao]

Context

v0.10.0 replaces the background auto-fetch's rolling "Every (hours)" interval with an "Every day at (UTC)" HH:MM field (default 06:00). The alarm now anchors to a wall-clock UTC time via alarms.create({ when: nextDailyUTC(...), periodInMinutes: 1440 }) instead of counting from enable-time.

The fetch → download → import_json.py half of the pipeline is already proven (v0.9.0 smoke test, #48, commit 2969f49). What's not yet verified live is the new when-anchored daily alarm scheduling path introduced in v0.10.0.

What to verify (Chrome, unpacked)

1. Load the unpacked extension; confirm popup shows v0.10.0 and the field reads "Every day at (UTC)".
2. Warm an open support.mozilla.org tab (browse it once so the Fastly challenge clears).
3. Set the time to a few minutes in the future (UTC), tick Auto-fetch on a schedule, approve the alarms permission.
4. Confirm the run fires at that UTC minute (not immediately, not at enable-time + N) and downloads the per-product bundles; last-run status updates in the popup.
5. Leave it enabled and confirm it fires again ~24h later at the same UTC time (re-anchors daily). A quick proxy: after the first fire, inspect the alarm's next scheduledTime (e.g. via chrome://extensions service-worker console: chrome.alarms.get('aaq-keepalive', a => console.log(a))) and confirm it equals the next day's chosen time.
6. Edit the time while enabled → confirm the alarm re-anchors to the new time (no duplicate alarms).
7. Migration: an install that previously stored intervalHours should default to 06:00 UTC with no error (stale key ignored).
8. Sleep behavior (optional): if the scheduled time passes while the Mac is asleep, confirm the run fires shortly after wake.

Not in scope

The fetch/import correctness itself (covered by #48). This issue is only about the scheduling behavior.