wip: e2e in ci

README.md

@@ -88,6 +88,13 @@ provide:
 - `script/test-e2e-firefox` — run the Firefox browser end-to-end suite (docker
   required; builds its own pinned image, see
   [End-to-End Tests](#end-to-end-tests))
+- `script/e2e-container` — `docker run` with this repo placed at `/work`, used
+  by both end-to-end suites. It copies the repo into the container instead of
+  bind-mounting it, because a bind mount does not resolve under Gitea Actions:
+  the runner executes the job inside a container against the host's docker
+  socket, so `-v "$PWD:/work"` is resolved by the host daemon and mounts an
+  empty directory. Copying is one mechanism for CI and for a laptop rather than
+  two, and costs about two seconds.
 - `script/lint` — run the linter
 - `script/fmt` — format all files (writes)
 - `script/fmt-check` — check formatting (read-only)
@@ -320,9 +327,35 @@ Two limits are worth knowing, both real differences from the Chrome suite:
 Neither `make test-e2e` nor `make test-e2e-firefox` is part of `make check` or
 `make test`. `REPO_POLICIES.md` caps `make test` at 20 seconds and a browser
 suite does not fit; nothing in `tests/e2e/` is named `*.test.js`, so jest cannot
-pick it up either. Neither is wired into the Gitea workflow yet —
-docker-in-docker in CI is a separate question. Run them locally before changing
-anything under `src/popup/views/`.
+pick it up either. Run them locally before changing anything under
+`src/popup/views/`.
+
+### In CI
+
+`.gitea/workflows/e2e.yml` runs both suites on every push, as two jobs —
+`e2e-chrome` and `e2e-firefox` — separate from the `check` workflow, so the
+20-second `make test` cap and the local fast path are untouched. Each job is
+`script/bootstrap` followed by the matching `make` target; the runner gives the
+job container the host's docker socket, which is what makes a nested browser
+container possible at all.
+
+The jobs **report, they do not gate.** A failure is a red mark against the
+commit that a reviewer has to account for, not a hard block: whether a check
+blocks a merge is Gitea branch protection, which this repo does not configure.
+Making `e2e-chrome` a required check is the intended end state and is
+deliberately not done yet, because the Chrome suite is flaky under load today
+and a gate that fails at random teaches people to merge past red.
+
+Nothing in either job can pass vacuously. There is no `continue-on-error` and no
+`|| true`; both scripts exit non-zero when docker is missing, when there is no
+extension build to load, and when the browser fails to start; the Chrome harness
+aborts the suite outright if its network interception is not in effect.
+
+Expect roughly 3-4 minutes for `e2e-chrome`, almost all of it the one-time pull
+of the pinned ~2GB Playwright image, and about 1 minute once that image is
+cached on the runner. `e2e-firefox` builds its own image, which downloads the
+Firefox tarball and geckodriver over the network on a cold cache: about 2
+minutes cold, about 40 seconds warm.
 
 ## Rationale