test: make e2e error attribution total, and fix the README canary text

The error collector had a window API (mark/since) and twice a record fell
outside somebody's window and was silently dropped, producing a green run
that proved nothing: first the mark started after test 1, discarding
everything recorded during launch; then the tail after the final test was
never read at all, so a request escaping the fixtures at the end of the
last test reported 5/5 passed and exit 0.

Rather than patch a second boundary and invite a third, the window
concept is gone. ErrorCollector exposes only take(), which always drains
everything outstanding, so successive takes partition the whole record
stream with no gaps, and seal(), which closes the stream at the end of
the run and routes stragglers straight to a failure. Attribution is
total by construction: launch through test 1 goes to test 1, each
subsequent interval to the test that ends it, the tail to the suite.

The tail also needs to exist before it can be drained. A request a test
fires without awaiting reaches the route handler about 10ms after that
test's function resolves, and closing the context does not wait for it,
so with no window at all it died unobserved. The run now keeps
collecting for a bounded 1.5s after the last test before teardown.

Also:

- README described a canary that was built, found to kill the service
  worker, and deleted. Replaced with what actually runs: the harness
  waits for the background worker's own startup blocklist fetch to reach
  the route handler and aborts if it does not. Documents
  --host-resolver-rules=MAP * ~NOTFOUND as defence in depth.
- The canary's failure message asserted traffic was escaping to the real
  internet and blamed the -e flag. It cannot distinguish that from a lost
  startup race, so it now states what was observed and lists both causes.
- E2E_TRACE_NETWORK was compared strictly to "1", so E2E_TRACE_NETWORK=true
  silently did nothing. Recognised on/off values are accepted and anything
  else is a hard error rather than a quiet default.
- The measured margin that makes the canary sound is route install at
  11-23ms against the worker fetch at 525-883ms, not the 30s timeout
  slack the comment cited.

README.md

@@ -104,12 +104,23 @@ allowed.
 That interception covers the MV3 background service worker as well as the popup
 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 fetches a
-`.invalid` URL from inside the service worker that only the route handler can
-answer, and aborts the entire suite if the answer does not come back. Escaping
-traffic fails the run instead of disappearing. To see what is actually being
-intercepted, run with `E2E_TRACE_NETWORK=1` and every routed request is printed,
-tagged `[sw]` or `[page]`.
+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
+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
+suite refuses to run rather than passing quietly.
+
+As defence in depth, Chrome is also started with
+`--host-resolver-rules=MAP * ~NOTFOUND`, so a request that ever did slip past
+the route handler could not resolve a host at all. That only bounds the damage;
+detecting escaping traffic remains the canary's job. To see what is actually
+being intercepted, run with `E2E_TRACE_NETWORK=1` and every routed request is
+printed, tagged `[sw]` or `[page]`.
 
 **Any uncaught page error or `console.error` fails the run.** That is the point:
 a `ReferenceError` from a used-but-not-imported identifier is invisible to