fix: drive background refresh and phishing update from alarms (closes #158)

README.md

@@ -149,10 +149,11 @@ page, which it does not by default — `script/test-e2e` sets
 `PW_EXPERIMENTAL_SERVICE_WORKER_NETWORK_EVENTS=1` for it. Because that flag is
 experimental, the harness does not take it on trust. At launch it waits for the
 background worker's **own** startup request — the phishing blocklist fetch that
-`src/background/index.js` issues unconditionally — to arrive in the route
-handler, and aborts the entire suite if none does within 30 seconds
-(`tests/e2e/harness.js`). The check is passive on purpose: a synthetic probe
-fetched from inside the worker via `worker.evaluate()` was tried first and
+`src/background/index.js` issues on startup, which on the suite's throwaway
+profile always happens because no previous fetch timestamp is persisted — to
+arrive in the route handler, and aborts the entire suite if none does within 30
+seconds (`tests/e2e/harness.js`). The check is passive on purpose: a synthetic
+probe fetched from inside the worker via `worker.evaluate()` was tried first and
 rejected, because evaluating in an extension service worker that early kills the
 worker outright, destroying the thing being measured. Observing traffic the
 extension already generates perturbs nothing. Losing the race fails closed — the
@@ -212,9 +213,10 @@ src/
     styles/main.css   — Tailwind source
     views/            — one JS module per screen (home, send, approval, etc.)
   shared/             — modules used by both popup and background
+    alarms.js         — recurring background jobs (extension alarms API)
     balances.js       — ETH + ERC-20 balance fetching via RPC + Blockscout
     constants.js      — chain IDs, default RPC endpoint, ERC-20 ABI
-    ens.js            — ENS forward/reverse resolution
+    ens.js            — ENS forward/reverse resolution (popup only)
     prices.js         — ETH/USD and token/USD via CoinDesk API
     scamlist.js       — known fraud contract addresses
     state.js          — persisted state (extension storage)
@@ -228,6 +230,74 @@ manifest/
   firefox.json        — Manifest V2 for Firefox
 ```
 
+### Background scheduling
+
+Chrome runs `src/background/index.js` as a Manifest V3 service worker, which the
+browser terminates after roughly 30 seconds idle and re-evaluates from scratch
+on the next event. Two consequences shape every recurring job in the background:
+
+- `setInterval` and `setTimeout` are useless. They are destroyed with the
+  worker, so a job scheduled that way runs until the first idle period and never
+  again. Both recurring jobs — the 60-second balance refresh and the 24-hour
+  phishing blocklist refresh — are scheduled through the extension alarms API
+  (`src/shared/alarms.js`) instead. The browser holds the schedule and wakes the
+  worker to deliver it. Alarm periods are clamped to a one-minute minimum, so
+  the balance refresh is expressed as exactly one minute and nothing is silently
+  slowed down.
+- Module-level variables do not survive either. Anything that must be remembered
+  across a restart goes in extension storage, including the timestamp of the
+  last phishing list fetch: without it a revived worker would either re-fetch on
+  every wake or, with a naive in-memory guard, never notice that an update is
+  due. `localStorage` does not exist in a service worker at all — the one
+  remaining user of it, `src/shared/ens.js`, runs only in the popup and is
+  marked as such.
+
+Both jobs also carry a freshness guard, and a guard must never be timed to the
+alarm period it gates. Each guard is measured from the moment the last run
+finished, which is one run-duration after the alarm that started it, so a guard
+of exactly one period vetoes the very next tick and the real cadence becomes two
+periods. The two jobs solve this differently, because their guards exist for
+different reasons:
+
+- The phishing refresh has a 24-hour cache TTL whose job is to keep the worker
+  off the network on the wakes between scheduled refreshes — Chrome revives the
+  worker every ~30 seconds while the browser is busy, and every revival runs the
+  startup path. The scheduled alarm tick is not one of those wakes, so it
+  bypasses the TTL and fetches unconditionally. Shortening the TTL instead would
+  not work: the startup path re-checks it on every wake, so a shorter TTL simply
+  becomes the real refresh rate.
+- The balance refresh guard exists to skip work an open popup has already done —
+  the popup refreshes every 10 seconds and stamps the same field. That has to
+  keep applying on the scheduled tick, so the guard is shortened to half the
+  alarm period instead of bypassed: comfortably above the popup's 10 seconds, so
+  an open popup still suppresses the background job, and comfortably below the
+  60-second period, so the schedule always wins.
+
+Two timestamps are persisted for the phishing list, not one. `lastFetchTime`
+records a fetch that produced a usable delta and drives the TTL.
+`lastAttemptTime` records that the network was contacted at all, and is written
+even when the result is unusable — a failed request, or a delta over the 256 KiB
+cap. Without it those cases leave no freshness mark and the worker re-downloads
+the full blocklist on every wake, indefinitely; with it, unscheduled retries are
+floored at one hour. Both are discarded on load if they are in the future, since
+a stamp from a skewed clock or a restored backup would otherwise suppress
+updates until that time arrives, permanently and with no way out.
+
+The startup path (`ensureRecurringAlarms()` plus the phishing list init) runs on
+`onInstalled`, on `onStartup`, and at the top level of the worker, so every way
+the background context can start re-establishes the schedule. On a fresh install
+more than one of those fires, so they share a single in-flight run rather than
+racing. It is idempotent: an alarm that already exists with the period the code
+asks for is left alone, because re-creating one restarts its schedule and a busy
+extension would push the next fire out indefinitely. An alarm carrying a
+different period — one created by an earlier version — is re-created once, or a
+period changed in a new release would never reach an existing install.
+
+Firefox uses Manifest V2 with a persistent background page, where timers would
+survive. Both browsers are built from one bundle and both take the alarm path,
+so there is a single code path to reason about; `"alarms"` is declared in both
+`manifest/chrome.json` and `manifest/firefox.json`.
+
 ### UI Design Philosophy
 
 The UI is inspired by _Universal Paperclips_. It's deliberately minimal,
@@ -938,9 +1008,14 @@ CoinDesk price API, and Blockscout API), AutistMask also contacts:
 - **Phishing domain blocklist**: A community-maintained phishing domain
   blocklist is vendored into the extension at build time. At runtime, the
   extension fetches the live list once every 24 hours to detect newly added
-  domains. Only the delta (domains not already in the vendored list) is kept in
-  memory, keeping runtime memory usage small. The delta is persisted to
-  localStorage if it is under 256 KiB.
+  domains, plus once on a start where the list is more than 24 hours old. Only
+  the delta (domains not already in the vendored list) is kept in memory,
+  keeping runtime memory usage small. The delta and the timestamp of the fetch
+  that produced it are persisted to extension storage if the record is under 256
+  KiB; an oversized delta is dropped along with its timestamp, so a later start
+  fetches again rather than claiming freshness for data it no longer holds. A
+  fetch that fails, or one whose delta was too large to store, is not retried
+  more than once an hour outside the 24-hour schedule.
 - **Etherscan address labels**: When confirming a transaction, the extension
   performs a best-effort lookup of the recipient address on Etherscan to check
   for phishing/scam labels. This is a direct page fetch with no API key; the
@@ -1183,6 +1258,12 @@ live list once every 24 hours and keeps only the delta (newly added domains not
 in the vendored list) in memory. This architecture keeps runtime memory usage
 small while ensuring fresh coverage of new phishing domains.
 
+The 24-hour cadence is an alarm, not a timer; the alarm tick fetches
+unconditionally rather than re-checking the 24-hour cache TTL that gates the
+startup path; and the fetch timestamps live in extension storage rather than in
+module variables — see [Background scheduling](#background-scheduling) for why
+all three are required.
+
 When a dApp on a blocklisted domain requests a wallet connection, transaction
 approval, or signature, the approval popup displays a prominent red warning
 banner alerting the user. The domain checker matches exact hostnames and all