diff --git a/.claude/skills/execplans/SKILL.md b/.claude/skills/execplans/SKILL.md
index 53c2e44..dc5025d 100644
--- a/.claude/skills/execplans/SKILL.md
+++ b/.claude/skills/execplans/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: execplans
-description: Write and maintain an ExecPlan — a self-contained, committed Markdown design document in docs/execplans/ — for work that spans more than one session or touches several files or subsystems. Use for a refactor crossing the container/view split, a tooling or dependency migration, adding CI or test coverage, #409's chart redraw path, or any change whose decisions and progress must survive a context reset. Also use when resuming or revising a plan already in docs/execplans/. Invoke with /execplans.
+description: Write and maintain an ExecPlan — a self-contained, committed Markdown design document in docs/execplans/ — for work that spans more than one session or touches several files or subsystems. Use for a refactor crossing the container/view split, a tooling or dependency migration, adding CI or test coverage, or any change whose decisions and progress must survive a context reset. Also use when resuming or revising a plan already in docs/execplans/. Invoke with /execplans.
 ---
 
 # ExecPlans
@@ -9,8 +9,7 @@ An ExecPlan is a Markdown design document that lives on disk and carries a piece
 design through implementation. It is the durable record: someone holding only the working tree and
 the plan file can pick the work up and finish it. Write one instead of relying on the built-in
 plan/todo tools whenever the work meets the threshold below — those tools don't survive a context
-reset, and this repo's near-term work (adding CI, broadening test coverage, fixing #409's chart
-redraw path) is exactly the kind that needs to.
+reset.
 
 Plans in this repository go in `docs/execplans/` and are committed on the working branch. **Read
 `references/PLANS.md` in full before writing or revising one** — it is the specification, and its
diff --git a/.claude/skills/execplans/references/PLANS.md b/.claude/skills/execplans/references/PLANS.md
index 4ab1c19..14bc85e 100644
--- a/.claude/skills/execplans/references/PLANS.md
+++ b/.claude/skills/execplans/references/PLANS.md
@@ -39,7 +39,7 @@ Write in plain prose. Prefer sentences over lists. Avoid checklists, tables, and
 
 ## Guidelines
 
-Self-containment and plain language are paramount. Assume the reader knows web development generally — npm scripts, React, CI, git — and define what is particular to this repository ("the container/view split", "react-refetch's `connect()`", "`flagForUpdate`", "the gitignored compiled CSS") the first time it appears, naming the files or commands where it shows up. Define each term once, in `Context and Orientation`, then use it. Do not say "according to the architecture doc"; put the needed explanation in the plan.
+Self-containment and plain language are paramount. Assume the reader knows web development generally — npm scripts, React, CI, git — and define what is particular to this repository ("the container/view split", "`withFetch`'s `dataFetch` prop", "`flagForUpdate`", "the gitignored compiled CSS") the first time it appears, naming the files or commands where it shows up. Define each term once, in `Context and Orientation`, then use it. Do not say "according to the architecture doc"; put the needed explanation in the plan.
 
 Avoid common failure modes. Do not rely on undefined jargon. Do not describe "the letter of a feature" so narrowly that the resulting code compiles but does nothing meaningful. Do not outsource key decisions to the reader. When ambiguity exists, resolve it in the plan itself and explain why you chose that path. Err on the side of over-explaining user-visible effects and under-specifying incidental implementation details.
 
@@ -171,7 +171,7 @@ branch. There is nowhere else for them here, and a plan that is not in the pull
 reviewable.
 
 `<slug>` is the kebab-case summary from the branch name, so the two line up: branch
-`409--hardware-resize-performance`, plan `docs/execplans/2026-09-20-hardware-resize-performance.md`.
+`409--hardware-resize-performance`, plan `docs/execplans/2026-10-28-hardware-resize-performance.md`.
 The date is the day the plan was started and does not change when the plan is revised.
 
 This specification is checked in at `.claude/skills/execplans/references/PLANS.md`. Cite that path
@@ -200,17 +200,19 @@ today. These do:
     npm run build:css         # required before Vitest on a fresh clone; the compiled CSS is gitignored
     npm run lint              # ESLint flat config (.js and .jsx) plus stylint
     npm run test:jest         # Vitest
-    npm run test:playwright   # Playwright, against the Vite dev server and live data.firefox.com
-    npm run build             # Vite production build plus version.json
+    npm run test:playwright   # every Playwright project, against the Vite dev server
+    npm run test:playwright:recorded  # the specs on the recorded fixtures (CI's required check)
+    npm run test:playwright:live      # the same specs on live data.firefox.com
+    npm run build             # Stylus compile, Vite production build, then version.json
     npm test                  # lint, then Vitest, then Playwright
 
-The Playwright dashboard specs assert against live production data, so a failure there can come
-from upstream data changing rather than from the commit. Re-run once before investigating, and say
-which it was.
+The recorded Playwright run is deterministic. Only `test:playwright:live` depends on upstream data,
+so a failure there can come from the data changing rather than from the commit; it usually means the
+recording is stale (see `AGENTS.md`). Say which it was.
 
 Run each command and report the actual result; never claim a pass you
-did not observe. State the expected result, not just the command: "`npm run test:jest` — 2 files, 4
-tests passing" beats "run the tests".
+did not observe. State the expected result, not just the command: "`npm run test:jest` — every file
+passes, including the new `Foo.test.jsx`" beats "run the tests".
 
 ## Record what matters, not what happened
 
@@ -264,7 +266,7 @@ neither self-contained nor, probably, correct.
 ## The plan and the pull request
 
 The plan file is part of the diff, so name it in the PR's **Significant changes and points to
-review** as one plain bullet — "Adds `docs/execplans/2026-09-14-eslint-unification.md`" — and stop
+review** as one plain bullet — "Adds `docs/execplans/2026-10-28-hardware-resize-performance.md`" — and stop
 there. The description keeps its four headings (One-line summary; Significant changes and points to
 review; Issue / Bugzilla link; Testing) and does not become a second copy of the plan. `AGENTS.md`'s
 ban on describing your own process still applies: the plan records how the work went, the
diff --git a/.claude/skills/update-deps/SKILL.md b/.claude/skills/update-deps/SKILL.md
index a0d7a4c..531ce50 100644
--- a/.claude/skills/update-deps/SKILL.md
+++ b/.claude/skills/update-deps/SKILL.md
@@ -2,14 +2,14 @@
 name: update-deps
 description: Audit and update npm dependencies
 disable-model-invocation: true
-argument-hint: "[all|sync-check|<package-name>]"
+argument-hint: "[all|<package-name>]"
 allowed-tools:
   - Bash(npm outdated *)
   - Bash(npm update *)
   - Bash(npm install *)
   - Bash(npm run lint*)
   - Bash(npm test*)
-  - Bash(npm run test-build*)
+  - Bash(npm run build*)
   - Bash(npm view *)
   - Bash(npm audit --json*)
   - Bash(npm explain *)
@@ -54,7 +54,7 @@ Indirect dependencies are packages in `package-lock.json` that aren't listed in
    - **No fix available**: report it and move on.
 4. Ask the user once whether to also refresh indirect dependencies that have no security fix pending (everything `npm update` would change within the existing ranges). Default to no; this can touch hundreds of packages.
 
-Never run `npm audit fix --force`. Its "fixes" with `isSemVerMajor: true` can be downgrades to old major versions of the parent (e.g. it suggests `@frctl/fractal@1.3.0`).
+Never run `npm audit fix --force`. Its "fixes" with `isSemVerMajor: true` can be downgrades to old major versions of the parent.
 
 ### Open Dependabot PRs
 
@@ -163,7 +163,7 @@ Record the following in `.claude/skills/update-deps/denied.md`:
 
 ## Phase 6: Execute Approved Updates
 
-Run `npm install <package>@<version>` for pinned packages, or `npm update <package>` for range-pinned packages. Verify `package-lock.json` updated correctly.
+Every direct dependency is exact-pinned, so run `npm install <package>@<version>`. Verify `package-lock.json` updated correctly.
 
 For indirect dependencies:
 
@@ -180,8 +180,8 @@ After each step, check `git diff package-lock.json` for packages that changed an
 After executing updates, offer to run verification commands:
 
 - `npm run lint` — run JS/CSS linting
-- `npm run test-build` — confirm the webpack build still succeeds
-- `npm test` — run the Jasmine browser test suite
+- `npm run build` — confirm the Stylus and Vite build still succeeds
+- `npm test` — run lint, the Vitest unit tests, and the Playwright suite
 
 Ask the user which (if any) they want to run. Run selected checks and report results.
 
diff --git a/AGENTS.md b/AGENTS.md
index 09c2ca5..758ea97 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -21,9 +21,9 @@
 | `containers/MetricOverviewContainer.jsx` | `${dashboardSource}/${activeRegion}/${slug}/index.json` | title, description, `type: 'line'｜'table'`, axes, columns, data, annotations |
 | `containers/SummaryMetricContainer.jsx` | same per-metric endpoint | buckets populations under 5% into "Other" |
 
-`src/lib/withFetch.jsx` **is the entire data layer** and is used in exactly those three files: `withFetch(props => url)(Container)` passes a `dataFetch` prop (`pending`, `rejected`, `fulfilled`, `value`, `reason`), refetches when the URL changes (back to pending first), rejects on non-2xx, and drops a response that arrives after a newer request started. Each one handles `dataFetch.pending` / `.rejected` / `.fulfilled` itself and renders `views/Spinner.jsx` or `views/Error.jsx`. All reshaping is client-side in each container's `formatData` (`ChartContainer` sorts populations by max y and drops nulls; `DataTableContainer` sorts rows by value descending).
+`src/lib/withFetch.jsx` **is the entire data layer** and is used in exactly those three files: `withFetch(props => url)(Container)` passes a `dataFetch` prop (`pending`, `rejected`, `fulfilled`, `value`, `reason`), refetches when the URL changes (back to pending first), rejects on non-2xx, and drops a response that arrives after a newer request started. Each one handles `dataFetch.pending` / `.rejected` / `.fulfilled` itself: `DashboardContainer` renders `views/Spinner.jsx` while pending, the two metric containers render nothing (the chart's own spinner shows instead), and all three render `views/Error.jsx` on rejection. All reshaping is client-side, in the `formatData` of `ChartContainer`, `DataTableContainer`, and `SummaryMetricContainer` (`ChartContainer` sorts populations by max y and drops nulls; `DataTableContainer` sorts rows by value descending).
 
-Metric `description` strings are rendered as inline Markdown through `markdown-it('zero')` with only `link`/`entity`/`emphasis`/`sup` enabled, via `dangerouslySetInnerHTML`. `src/tests/jest/MetricOverview.test.jsx` exists **specifically to guard that sanitization** — never widen the enabled-rules list without extending that test.
+Metric `description` strings are rendered as inline Markdown through `markdown-it('zero')` with only `link` and `entity` enabled plus the `markdown-it-sup` plugin, via `dangerouslySetInnerHTML`. The dashboard description in `views/Dashboard.jsx` enables only `emphasis`. `src/tests/jest/MetricOverview.test.jsx` exists **specifically to guard that sanitization** — never widen the enabled-rules list without extending that test.
 
 ```
 src/
@@ -47,10 +47,10 @@ src/
 └── tests/
     └── jest/                    unit tests, run by Vitest (the directory name predates Vitest)
 tests/playwright/
-├── specs/                       e2e specs (.spec.js, CommonJS), incl. dashboards/ and fixtures/; run on the recording and on live data
+├── specs/                       e2e specs (.spec.js, CommonJS), incl. dashboards/ and fixtures/; run on the recording, and all but fixtures/ and jsDisabled also on live data
 ├── fixtures/                    recorded transposer JSON, written by `npm run record:fixtures`
 ├── fixtureData.js               `test` that serves fixtures/ (or live data, with liveData) and fails on page/console errors; readFixture
-└── utils.js                     shared helpers: linkWorks, linksWork, flagForUpdate, metricTitleIsCorrect
+└── utils.js                     shared helpers: formatPercent, linkWorks, linksWork, flagForUpdate, metricTitleIsCorrect, changeRegionAndWaitForMetrics
 ```
 
 There is no `pages/`, `store/`, `hooks/`, `api/`, `locales/`, or `data/`. `index.html` at the repository root is Vite's entry point (with a hardcoded `og:image` and the `<noscript>` message). `public/` holds static files copied as-is: `manifest.json`, `contribute.json`, a Search Console verification file, and `img/`. `build/` is gitignored output. `docs/architecture/` describes the frontend and the data pipeline. Routes are exactly `/`, `/contact`, `/dashboard/<key>`, and a catch-all `NotFound`.
@@ -59,11 +59,11 @@ There is no `pages/`, `store/`, `hooks/`, `api/`, `locales/`, or `data/`. `index
 
 MozMEAO is taking this repo over. Before that work started there were 810 commits — 515 in 2018, 92 in 2020, **nothing in 2021–2024**, three in 2025, the last `f655559` on 2025-05-07. The toolchain has since been replaced (#441): create-react-app, Jest and Nightwatch gave way to Vite, Vitest and Playwright, and two ESLint configs became one. Code outside the toolchain has barely been exercised since 2020.
 
-- **CI and CD both run on GitHub Actions.** `.github/workflows/ci.yml` runs lint, the Vitest unit tests, a production build (`npm run build`, not browser-tested), and the Playwright end-to-end tests on every push to `main` and every pull request. The Playwright specs run twice: on recorded data in "End-to-end tests", which the `main` ruleset requires, and on live data in "Live data tests", which it doesn't. `ssdlc-actions.yml` (zizmor and Semgrep into code scanning) and `sbom.yml` (a CycloneDX SBOM per commit on `main` and per release) call Mozilla's shared reusable workflows in `mozilla/ssdlc-actions`, pinned by SHA; keep the pin in step with bedrock's. There is no `.circleci/`, `Dockerfile`, `docker-compose`, or `Jenkinsfile` — earlier automation was deliberately removed: CircleCI disabled 2018-02-22 (`433a465`), Docker/Dockerflow removed 2018-08-23 (`d3bb561`), `.github/dependabot.yml` deleted 2020-07-29 (`7c7006f`, "Disable non-security updates from Dependabot").
-- **The deploy is a static build on Google Cloud Storage** (confirmed by `x-goog-*` headers on the live site). `https://data.firefox.com/version.json` reports `1.2.1` / commit `f655559`, so **the deployed site predates the Vite toolchain on `main`**; nothing built by Vite has shipped yet. `.github/workflows/deploy.yml` deploys `main` to stage and GitHub releases to prod, via Workload Identity (no secrets). The bucket is shared with the transposer's `datasets/`, nothing in the deploy deletes, and deep links only work because `index.html` is copied to each route path. `docs/architecture/deploy.md` records the buckets, CDN, access, and open questions — read it before changing anything about hosting or the workflow.
+- **CI and CD both run on GitHub Actions.** `.github/workflows/ci.yml` runs lint, a production build (`npm run build`, not browser-tested; it also compiles the Stylus the unit tests import), the Vitest unit tests, and the Playwright end-to-end tests on every push to `main` and every pull request. The Playwright specs run twice: on recorded data in "End-to-end tests", which the `main` ruleset requires along with "Lint and test", and on live data in "Live data tests", which it doesn't. `ssdlc-actions.yml` (zizmor and Semgrep into code scanning) and `sbom.yml` (a CycloneDX SBOM per commit on `main` and per release) call Mozilla's shared reusable workflows in `mozilla/ssdlc-actions`, pinned by SHA; keep the pin in step with bedrock's. There is no `.circleci/`, `Dockerfile`, `docker-compose`, or `Jenkinsfile` — earlier automation was deliberately removed: CircleCI disabled 2018-02-22 (`433a465`), Docker/Dockerflow removed 2018-08-23 (`d3bb561`), `.github/dependabot.yml` deleted 2020-07-29 (`7c7006f`, "Disable non-security updates from Dependabot"). Dependabot came back in #453: `.github/dependabot.yml` groups updates, waits out a 7-day cooldown, and holds back the majors it lists, with reasons.
+- **The deploy is a static build on Google Cloud Storage** (confirmed by `x-goog-*` headers on the live site). `https://data.firefox.com/version.json` reports `1.2.1` / commit `f655559`, so **prod predates the Vite toolchain on `main`**; no Vite build has reached prod yet, though stage serves one from every push to `main`. `.github/workflows/deploy.yml` deploys `main` to stage and GitHub releases to prod, via Workload Identity (no secrets). The bucket is shared with the transposer's `datasets/`, nothing in the deploy deletes, and deep links only work because `index.html` is copied to each route path. `docs/architecture/deploy.md` records the buckets, CDN, access, and open questions — read it before changing anything about hosting or the workflow.
 - **Node 24.** `.nvmrc` holds `24` and `engines` requires `^24.15.0`. A plain `npm install` works with no flags.
-- **A fresh clone will not render styles until you compile Stylus.** `src/components/views/css/*` is gitignored and every component does a side-effect `import './css/Foo.css';` — run `npm run build:css` or the app, and Vitest, fail to resolve those imports. `npm start` compiles it for you.
-- About 30 open issues, oldest from 2018. Notables: #313 (`MetricOverviewContainer` does not reject when metric data 404s — cited in an inline comment there), #245 (React code-splitting), #46 (localize content). #333 (replace `@babel/polyfill`) is still open, but the polyfill was removed in #441. The remote also carries about 30 stale `dependabot/npm_and_yarn/*` branches and three `%archive-*` branches.
+- **A fresh clone will not render styles until you compile Stylus.** `src/components/views/css/*` is gitignored and most views do a side-effect `import './css/Foo.css';` — run `npm run build:css` or the app, and Vitest, fail to resolve those imports. `npm start` compiles it for you.
+- Open issues date back to 2018, and many predate the toolchain replacement. Check an old issue against the current code before working on it.
 - Upstream data is **live and current** — transposer `dates` arrays are sorted newest-first and are updated weekly. The app is unmaintained; the data is not.
 
 ## Build, Test, and Development Commands
@@ -98,7 +98,7 @@ Run one Vitest file: `npx vitest run src/tests/jest/Dashboard.test.jsx`. Run one
 
 - **`.jsx` for any file containing JSX** — including `src/index.jsx` and `*.test.jsx`. Plain `.js` only for non-JSX modules (`lib/utils.js`, `setupTests.js`, `registerServiceWorker.js`, the Playwright specs and helpers, and the config files at the repository root).
 - **PascalCase filenames matching the default-exported component.** Decorators are camelCase with a `with` prefix; `lib/lazyLoad.jsx` and `lib/withFetch.jsx` are camelCase because they are helpers, not components.
-- **One component per file, always `export default`.** There are no named component exports anywhere in the repo; the only named exports at all are the four helpers in `lib/utils.js`.
+- **One component per file, always `export default`.** There are no named component exports anywhere in the repo; the only named exports at all are the four helpers in `lib/utils.js` and `unregister` in `registerServiceWorker.js`.
 - **The container/view split is the organizing principle.** `containers/X.jsx` holds state and fetching and renders `views/X.jsx` with formatted props (`ChartContainer`→`Chart`, `DataTableContainer`→`DataTable`). Keep new state out of `views/`.
 - Function components are the default (15 of 20 views), written as anonymous default-exported arrows — `export default props => (...)` — with no `displayName` (hence `react/display-name: off`). The router is react-router 7, imported from `react-router` (not `react-router-dom`), and read with its `useLocation()` hook, in `views/Main.jsx` and both decorators (`withTracker` sends its page view from a `useEffect` on the pathname). Use a class only where state, refs, or lifecycle are genuinely needed: all 6 containers plus `SummaryMetric.jsx` (d3 + `React.createRef`), `MetricsGraphics.jsx` (metrics-graphics + `React.createRef`), `Spinner.jsx`, `MetricOverview.jsx`, `Footer.jsx`, and `lib/LazyBoundary.jsx` (error boundaries must be classes).
 - Leading underscore for private class-property handlers (`_onRegionChange`, `_drawChart`, `_setChartSize`). Keep using it in new code.
@@ -118,7 +118,7 @@ Errors: `eqeqeq`, `no-var`, `prefer-const`, `no-console`, `no-global-assign`, `n
 
 Shared variables live in `src/components/views/styl/includes/lib.styl` and it is nearly empty — `$base-tablet`, `$base-desktop`, `$link-color-normal = #0070ff`, and a `// TODO: padding/margin spacing.`. Import it per-file with `@import 'includes/lib'`; it is not globally injected. **No mixins file; most colors are hardcoded hex inline** (stylint's `colors` check is off).
 
-**Not BEM.** ID selectors carry the page landmarks — `#application`, `#main-header`, `#main-navigation`, `#dashboard`, `#dashboard-sections`, `#summary-metrics`, `#region`, `#introduction` — with flat lowercase-dash classes for repeated pieces (`.metric-overview`, `.dashboard-section`, `.data-table-wrapper`, `.labelled-selector`, `.next-button`, `.striped`, `.highlighted`, `.bar-label`). Descendant nesting with `&` for states; responsive via `@media $base-tablet` / `@media $base-desktop` blocks at the bottom of each file. **Those element IDs are also the Playwright selectors — renaming one breaks the e2e tests.**
+**Not BEM.** ID selectors carry the page landmarks — `#application`, `#main-header`, `#main-navigation`, `#dashboard`, `#summary-metrics`, `#region`, `#introduction` — with flat lowercase-dash classes for repeated pieces (`.metric-overview`, `.dashboard-section`, `.data-table-wrapper`, `.labelled-selector`, `.next-button`, `.striped`, `.highlighted`, `.bar-label`). Descendant nesting with `&` for states; responsive via `@media $base-tablet` / `@media $base-desktop` blocks at the bottom of each file. **Those element IDs are also the Playwright selectors — renaming one breaks the e2e tests.**
 
 stylint (`.stylintrc`) runs with `maxErrors: 0` and `maxWarnings: 0`, so any finding fails the lint. It enforces the **CSS-like** Stylus dialect, not the terse indented syntax: 4-space indent, single quotes, `brackets: always`, `colons: always`, `semicolons: always`. Also `noImportant: true`, `leadingZero: false` (`.5`, not `0.5`), `zeroUnits: never` (`0`, not `0px`), `universal: never` (no `*`), `prefixVarsWithDollar: always`, `namingConvention: lowercase-dash` with `namingConventionStrict: true`, `zIndexNormalize: 10`. Escape hatches are `// @stylint off` / `on` / `ignore` comments — see the `@font-face` block in `Application.styl`.
 
@@ -144,7 +144,7 @@ This applies to everything written for a person to read: ExecPlans, PR descripti
 
 ## Testing Guidelines
 
-**Vitest + React Testing Library**, configured in the `test` block of `vite.config.mjs` (`jsdom`, `globals: true`, `include: ['src/tests/jest/**/*.test.jsx']`). Files live in `src/tests/jest/`, named `PascalCase.test.jsx` — **not colocated, no `__tests__` directories.** JSX uses the automatic runtime, so neither components nor tests import React just for JSX; tests import `render`, `screen`, and `waitFor` from `@testing-library/react`. `src/setupTests.js` registers the jest-dom matchers (`toHaveTextContent`, `toBeInTheDocument`), and **fails any test that calls `console.error` unexpectedly**, so React warnings surface as failures — a test that expects an error replaces `console.error` with `vi.spyOn(console, 'error').mockImplementation(() => {})`. Tests render the real component tree into jsdom and assert on the DOM (`container.querySelector('#dashboard-description')`, or `innerHTML` where the markup itself is the point, as in the sanitization test). Existing style is top-level `it(...)` with long descriptive sentences. No snapshots.
+**Vitest + React Testing Library**, configured in the `test` block of `vite.config.mjs` (`jsdom`, `globals: true`, `include: ['src/tests/jest/**/*.test.jsx']`). Files live in `src/tests/jest/`, named after the module under test (`Dashboard.test.jsx`, `withFetch.test.jsx`) — **not colocated, no `__tests__` directories.** JSX uses the automatic runtime, so neither components nor tests import React just for JSX; tests import `render`, `screen`, and `waitFor` from `@testing-library/react`. `src/setupTests.js` registers the jest-dom matchers (`toHaveTextContent`, `toBeInTheDocument`), and **fails any test that calls `console.error` unexpectedly**, so React warnings surface as failures — a test that expects an error replaces `console.error` with `vi.spyOn(console, 'error').mockImplementation(() => {})`. Tests render the real component tree into jsdom and assert on the DOM (`container.querySelector('#dashboard-description')`, or `innerHTML` where the markup itself is the point, as in the sanitization test). Existing style is top-level `it(...)` with long descriptive sentences. No snapshots.
 
 - **Stubbing the network:** `withFetch` calls `window.fetch(new Request(url, …))` each time it fetches. Stub it with `fetchMock = vi.spyOn(window, 'fetch')` in `beforeEach` (`setupTests.js`'s `vi.restoreAllMocks()` undoes it) and read URLs from `fetchMock.mock.calls[n][0].url`. The container tests (`SummaryMetricContainer.test.jsx` is the simplest) show the pattern.
 - **Waiting for lazy routes:** wait with React Testing Library's `waitFor` / `findBy*`, never `vi.waitFor`. RTL turns off React's act() check while it waits, so a `React.lazy` component can resolve. Under `vi.waitFor`, or after a test that returns while a lazy route is still loading, React 18 logs "A suspended resource finished loading inside a test, but the event was not wrapped in act(...)", and the console.error trap turns that into an unhandled error that fails the run.
@@ -152,7 +152,7 @@ This applies to everything written for a person to read: ExecPlans, PR descripti
 - **Testing chart views:** `Chart.test.jsx` renders the real `views/Chart` with `vi.mock('../../components/views/MetricsGraphics', () => ({ default: vi.fn(() => null) }))` and asserts on the options it computes (bounds, units, UTC formatting, legend, markers, colors). `SummaryMetric.test.jsx` renders the real d3 summary bar inside `<div id="application"><main>`, with `vi.spyOn(HTMLElement.prototype, 'offsetWidth', 'get').mockReturnValue(490)` — jsdom reports 0px, and at 490px the bar draws at its 450px maximum, so segment widths are predictable.
 - **Routing:** `Routes.test.jsx` renders `views/Application` inside `MemoryRouter` through one `renderAt(path)` function — the only place a router upgrade has to touch — wraps it in react-helmet-async's `HelmetProvider` (any test that renders a page with a `<Helmet>` needs one — `render(ui, { wrapper: HelmetProvider })`), and mocks `react-ga4` so no analytics load. Its cases are generated from `config.json`, so adding a dashboard adds a route test.
 
-**Playwright** specs in `tests/playwright/specs/` are **`camelCase.spec.js` or `kebab-case.spec.js`, CommonJS**. Every spec except `jsDisabled.spec.js` imports `test`, `expect` (and, where needed, `readFixture`) from **`tests/playwright/fixtureData.js`**, not `@playwright/test`. `tests/playwright/utils.js` exports `linkWorks`, `linksWork`, `metricTitleIsCorrect`, `changeRegionAndWaitForMetrics`, and `flagForUpdate` — which **deliberately fails when an element count changes**, to force a human to look.
+**Playwright** specs in `tests/playwright/specs/` are **`camelCase.spec.js` or `kebab-case.spec.js`, CommonJS**. Every spec except `jsDisabled.spec.js` imports `test`, `expect` (and, where needed, `readFixture`) from **`tests/playwright/fixtureData.js`**, not `@playwright/test`. `tests/playwright/utils.js` exports `formatPercent`, `linkWorks`, `linksWork`, `metricTitleIsCorrect`, `changeRegionAndWaitForMetrics`, and `flagForUpdate` — which **deliberately fails when an element count changes**, to force a human to look.
 
 **The same specs run in two modes**, chosen by Playwright project in `playwright.config.js`:
 
@@ -182,7 +182,7 @@ In recorded mode, `fixtureData.js`'s `test` answers every `https://data.firefox.
 | `build:version.json` | Needs `build/` to already exist and `git` on PATH; must follow `build:app`. |
 | `no-shadow` / `no-redeclare` with `builtinGlobals` | Naming a local `name`, `status`, `history`, `event` is a hard error. |
 
-**Known rot, for recognition only — this file is not a roadmap:** `registerServiceWorker.js` exists but only `unregister()` is called, and its registration path still reads create-react-app's `process.env.PUBLIC_URL`; `dateformat@3.0.3` is several majors behind, because newer majors change its export shape (see `docs/architecture/frontend.md`).
+**Known rot, for recognition only — this file is not a roadmap:** `registerServiceWorker.js` exists but only `unregister()` is called, and its registration path still reads create-react-app's `process.env.PUBLIC_URL`.
 
 ## Workflow guidelines
 
@@ -192,9 +192,9 @@ In recorded mode, `fixtureData.js`'s `test` answers every `https://data.firefox.
 
 ### ExecPlans
 
-Work that spans more than one session — #409's redraw path, broadening test coverage — gets an **ExecPlan**: a self-contained Markdown design document, written before the code, committed with it, and kept current as the work moves. The specification is `.claude/skills/execplans/references/PLANS.md`; the `execplans` skill loads it on demand, so read it there rather than guessing at the shape.
+Work that spans more than one session — as #409's redraw fix and the test-coverage work did — gets an **ExecPlan**: a self-contained Markdown design document, written before the code, committed with it, and kept current as the work moves. The specification is `.claude/skills/execplans/references/PLANS.md`; the `execplans` skill loads it on demand, so read it there rather than guessing at the shape.
 
-Plans live in `docs/execplans/`, named `YYYY-MM-DD-kebab-case-summary.md` (`2026-09-14-eslint-unification.md`), and ship on the branch with the change so a reviewer reads the plan and the diff together. Update the plan in the same commit as the work it describes — a plan that lags the tree is worse than no plan.
+Plans live in `docs/execplans/`, named `YYYY-MM-DD-kebab-case-summary.md` (`2026-10-28-hardware-resize-performance.md`), and ship on the branch with the change so a reviewer reads the plan and the diff together. Update the plan in the same commit as the work it describes — a plan that lags the tree is worse than no plan.
 
 A single-file fix does not need one. Neither does anything you could put in a commit title.
 
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 4a08440..9abba2f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -15,8 +15,11 @@ how to work in the code, not what the code is.
 
     npm run lint                         # lint:js (flat-config ESLint, covers .js and .jsx) + lint:styl
     npm run test:jest                    # vitest run; confirmed passing, no flags
-    npm test                             # lint -> test:jest -> test:playwright
+    npm test                             # lint -> test:jest -> test:playwright -> npm audit
+                                          # (posttest; never fails)
 
+    npm run build                        # build:css -> build:app -> build:version.json (what CI and
+                                          # the deploy run)
     npm run build:app                    # vite build; confirmed working, no flags needed
     npm run build:version.json           # writes build/version.json; must run after build:app, needs git on PATH
     npm run size                         # source-map-explorer on build/assets/index-*.js (rebuilds build/ with source maps first)
@@ -48,15 +51,16 @@ plain text, so a real credential never belongs in one, and this `.env` file deli
   `with` prefix; `lib/lazyLoad.jsx` and `lib/LazyBoundary.jsx` are the exceptions (a small loader
   helper and an error-boundary component, not components themselves in the first case).
 - One component per file, always `export default`. There are no named component exports anywhere in
-  this repository; the only named exports at all are the four helpers in `lib/utils.js`.
+  this repository; the only named exports at all are the four helpers in `lib/utils.js` and
+  `unregister` in `registerServiceWorker.js`.
 - The container/view split is the organizing principle — see `docs/architecture/frontend.md`.
   `containers/X.jsx` holds state and fetching and renders `views/X.jsx` with formatted props
   (`ChartContainer` → `Chart`, `DataTableContainer` → `DataTable`). Keep new state out of `views/`.
-- Function components are the default (17 of 19 views), written as anonymous default-exported
+- Function components are the default (15 of 20 views), written as anonymous default-exported
   arrows — `export default props => (...)` — with no `displayName` (hence `react/display-name:
   off`). Use a class only where state, refs, or lifecycle are genuinely needed: all 6 containers
-  plus `SummaryMetric.jsx` (d3 + `React.createRef`), `Spinner.jsx`, `MetricOverview.jsx`,
-  `Footer.jsx`, and `LazyBoundary.jsx` (an error boundary, which must be a class component).
+  plus `SummaryMetric.jsx` (d3 + `React.createRef`), `MetricsGraphics.jsx` (metrics-graphics +
+  `React.createRef`), `Spinner.jsx`, `MetricOverview.jsx`, `Footer.jsx`, and `LazyBoundary.jsx` (an error boundary, which must be a class component).
 - Leading underscore for private class-property handlers (`_onRegionChange`, `_drawChart`,
   `_setChartSize`). Keep using it in new code.
 - Locals named `maybeX` hold a JSX fragment or `null` (`maybeDescription`, `maybeSummaryMetrics`,
@@ -76,15 +80,16 @@ plain text, so a real credential never belongs in one, and this `.env` file deli
 `.jsx`.** `npm run lint:js` runs `eslint .` with no other flags; there is no separate config for
 `.jsx` and no invisible bundled config supplying one either (unlike the old create-react-app-era
 setup, which linted `.jsx` invisibly through `react-scripts`). Errors: `eqeqeq`, `no-var`,
-`prefer-const`, `no-console`, `no-global-assign`, `no-redeclare` and `no-shadow` — the latter two
-with `builtinGlobals: true`, so do not name a variable `name`, `status`, `history`, `event`, etc.
+`prefer-const`, `no-console`, `no-global-assign`, `jsx-a11y/label-has-associated-control` (with
+`assert: 'htmlFor'`), `no-redeclare` and `no-shadow` — the latter two with `builtinGlobals: true`,
+so do not name a variable `name`, `status`, `history`, `event`, etc.
 Warnings: `semi: always`, `prefer-arrow-callback`, `comma-dangle` (trailing commas required for
 multiline arrays, objects, imports, and exports; never for function args or params). Off:
 `react/prop-types`, `react/display-name`, `jsx-a11y/no-onchange`. `react/no-unescaped-entities`
 forbids only `>` and `}`. `settings.react.version` is `'detect'` (reads the installed React version
 automatically, rather than a hardcoded string). `src/tests/jest/**/*.test.jsx` additionally gets
 `@vitest/eslint-plugin`'s recommended rules and Vitest's ambient globals (`it`, `expect`,
-`beforeAll`, etc. — the same globals `src/setupTests.js` attaches for the tests themselves). Quote
+`beforeAll`, etc. — the same globals `globals: true` in `vite.config.mjs` provides at run time). Quote
 style is not enforced (there is no `quotes` rule) — single quotes by convention. The `build`
 directory is excluded via the config's own `ignores` array (flat config's replacement for
 `.eslintignore`, which no longer exists).
@@ -103,7 +108,7 @@ spacing.` comment. Import it per-file with `@import 'includes/lib'` — it is no
 There is no mixins file; most colors are hardcoded hex inline (stylint's `colors` check is off).
 
 This styling is not BEM. ID selectors carry the page landmarks — `#application`, `#main-header`,
-`#main-navigation`, `#dashboard`, `#dashboard-sections`, `#summary-metrics`, `#region`,
+`#main-navigation`, `#dashboard`, `#summary-metrics`, `#region`,
 `#introduction` — with flat lowercase-dash classes for repeated pieces (`.metric-overview`,
 `.dashboard-section`, `.data-table-wrapper`, `.labelled-selector`, `.next-button`, `.striped`,
 `.highlighted`, `.bar-label`). Descendant nesting with `&` handles states; responsive rules live in
@@ -177,8 +182,8 @@ repository root. Specs are `camelCase.spec.js` or `kebab-case.spec.js` (matching
 page under test), CommonJS. Every spec except `jsDisabled.spec.js` imports `test`, `expect` and,
 where needed, `readFixture` from `tests/playwright/fixtureData.js` rather than from
 `@playwright/test` — for example `test('Page loads', async ({ page }) => { await
-expect(page.locator('#contact')).toBeVisible(); })`. Shared helpers (`linkWorks`, `linksWork`,
-`flagForUpdate`, `metricTitleIsCorrect`, `changeRegionAndWaitForMetrics`) live in
+expect(page.locator('#contact')).toBeVisible(); })`. Shared helpers (`formatPercent`, `linkWorks`,
+`linksWork`, `flagForUpdate`, `metricTitleIsCorrect`, `changeRegionAndWaitForMetrics`) live in
 `tests/playwright/utils.js`. `linkWorks` and `linksWork` check only links within the app and skip
 external URLs, which failed too often for reasons outside this repository. `flagForUpdate`
 deliberately fails when an element count changes, to force a human to look. Playwright starts the
@@ -266,10 +271,7 @@ style indirection layer, so a failure points straight at the markup it cares abo
 Known rot, recorded for recognition only, not as a roadmap: `react-app-polyfill` and
 `babel-polyfill`, plus a `browserslist` of `>0.2%, not dead, not ie <= 10, not op_mini all`, were
 IE11-era targeting — both removed in the Vite migration, since IE11 support was already effectively
-dead. `dateformat@3.0.3` is several majors behind current, but the newer majors change its module
-export shape in a way that needs call-site changes, not just a version bump — deliberately left
-alone (see `docs/architecture/frontend.md`'s dependency-ceiling section). `distinct-colors@3.0.0`
-has no newer major.
+dead. `distinct-colors@3.0.0` has no newer major.
 
 ## Git workflow
 
@@ -293,7 +295,7 @@ This project maintains a hand-managed version number in `package.json` that is n
 first digit for major changes, the second for medium, the third for small — historically bumped at
 deploy time. Do not bump it casually; ask.
 
-If a changeset adds a GitHub Action or workflow (there are none today), check it with
+If a changeset adds or changes a GitHub Actions workflow in `.github/workflows/`, check it with
 [Zizmor](https://zizmor.sh/) before considering the work complete.
 
 ### Writing PR descriptions
diff --git a/README.md b/README.md
index d807deb..a6013d0 100644
--- a/README.md
+++ b/README.md
@@ -3,8 +3,9 @@ Report](https://data.firefox.com), a weekly public report on the activity,
 behavior, and hardware configuration of Firefox Desktop users.
 
 Ensemble fetches data from
-[ensemble-transposer](https://github.com/mozilla/ensemble-transposer), a JSON
-server that adds metadata to the raw data hosted by Mozilla data engineers.
+[ensemble-transposer](https://github.com/mozilla/ensemble-transposer), a weekly
+job that adds metadata to the raw data published by Mozilla data engineers and
+writes the result as JSON under `data.firefox.com/datasets/`.
 See [`docs/architecture/data-pipeline.md`](docs/architecture/data-pipeline.md)
 for how that data is generated upstream, where it lives, and which
 repositories are involved.
@@ -23,8 +24,8 @@ Any of the environment variables in *.env* can be overridden. For example:
 
 ### In production
 
-Run `npm run build:app` to produce a static build in `build/` (see `CONTRIBUTING.md` for the full
-command reference). See [`docs/architecture/deploy.md`](docs/architecture/deploy.md) for where that build is
+Run `npm run build` to produce a static build in `build/` (Stylus, then Vite, then `version.json`;
+see `CONTRIBUTING.md` for the full command reference). See [`docs/architecture/deploy.md`](docs/architecture/deploy.md) for where that build is
 hosted and how it is deployed: pushes to `main` deploy to stage and GitHub releases deploy to prod,
 via `.github/workflows/deploy.yml`.
 
diff --git a/docs/architecture/deploy.md b/docs/architecture/deploy.md
index 46c0411..88ad359 100644
--- a/docs/architecture/deploy.md
+++ b/docs/architecture/deploy.md
@@ -22,9 +22,9 @@ Workgroup = a managed group of people granted access to GCP resources.
 | Bucket | `moz-fx-data-static-websit-8565-ensemble` | `moz-fx-data-static-websit-f7e0-ensemble` |
 | Hostname | `data.firefox.com` | `dfc-stage.data-static-websites.nonprod.webservices.mozgcp.net` |
 | DNS | CNAME to `dfc-prod.data-static-websites.prod.webservices.mozgcp.net` | no vanity domain |
-| Front-end content | v1.2.1, commit `f655559`, uploaded 2025-05-12 | v1.2.0, commit `f0658a8`, uploaded 2023-06-14 |
+| Front-end content | v1.2.1, commit `f655559`, uploaded 2025-05-12 | tracks `main`; every push to `main` deploys |
 | `datasets/` content | rewritten weekly by the transposer | snapshot from 2023-06-19, never updated |
-| Deep links | work (see below) | 404 until the first deploy from `main` |
+| Deep links | work (see below) | work (see below) |
 
 Both buckets belong to the `data-static-websites` tenant in
 [`mozilla/webservices-infra`](https://github.com/mozilla/webservices-infra/tree/main/data-static-websites),
@@ -36,9 +36,8 @@ administered by the `dataplatform/admins` workgroup. The tenant's `risk_level` i
 Ensemble is one entry, keyed `"ensemble"`, in the `cdn` map in `tf/prod/locals.tf` and
 `tf/stage/locals.tf`, plus a `module "ensemble_bucket"` block in each environment's `cdn.tf`. Both
 were added by Data Engineering in June 2023 (`d0975e2519` stage, `609c8b4fb8` prod) when the site
-moved from AWS to GCP. Stage was uploaded to once, as part of that move, and never again.
-`public/contribute.json` still lists the AWS-era stage host `data-ensemble.stage.mozaws.net`, which
-no longer resolves.
+moved from AWS to GCP. Stage was uploaded to once, as part of that move, and not again until the
+deploy workflow below.
 
 ## How requests are served
 
@@ -52,17 +51,17 @@ Live responses carry `age:` headers of several hours. Purging the cache needs
 include.
 
 **Cache headers.** The CDN rewrites every outgoing `cache-control` to `public,max-age=0`. On the
-objects themselves, `index.html` and the route copies carry `no-cache, max-age=0, must-revalidate`
-(set when they were uploaded); everything else, including content-hashed JS, carries GCS's default
-`public, max-age=3600`. Long-lived caching of hashed assets is therefore not in effect today and
-cannot be achieved by object metadata alone while `FORCE_CACHE_ALL` is set.
+objects themselves, the deploy workflow sets the headers listed under "How deploys work", including
+`immutable` on content-hashed assets. Prod's 2025-05-12 hand upload predates that: its `index.html`
+and route copies carry `no-cache, max-age=0, must-revalidate`, and everything else carries GCS's
+default `public, max-age=3600`. Either way, long-lived caching of hashed assets is not in effect at
+the edge and cannot be achieved by object metadata alone while `FORCE_CACHE_ALL` is set.
 
 **Deep links.** The URL map has no rewrite rules. Deep links work on prod because the bucket holds
 objects named `dashboard/hardware`, `dashboard/user-activity`, `dashboard/usage-behavior`, and
 `contact`, each a byte-identical copy of `index.html` (same etag). They were uploaded 40 minutes
-after `index.html` on 2025-05-12, by hand. Stage has no such copies, so every stage deep link
-returns 404. Any deploy process has to recreate these copies, one per route in `src/config.json`
-plus `/contact`.
+after `index.html` on 2025-05-12, by hand. Any deploy process has to recreate these copies, one per
+route in `src/config.json` plus `/contact`.
 
 **404s.** Unknown paths and trailing-slash variants (`/dashboard/hardware/`) return GCS's XML 404
 with HTTP status 404. The bucket's website configuration names `404.html`, but load-balancer backend
@@ -111,8 +110,9 @@ a pre-release) deploys to prod. A manual run deploys the current ref to a chosen
 `prod` GitHub environment only accepts tags, so a prod re-run or rollback is "run the workflow from
 tag X". Deploys to one environment are serialised and never cancelled midway.
 
-The job authenticates with Workload Identity Federation (no secrets or variables in the repo), builds,
-then uploads in this order:
+The `deploy` job builds with `npm run build` (Stylus, then Vite, then `version.json`; no source
+maps), authenticates with Workload Identity Federation (no secrets or variables in
+the repo), then uploads in this order:
 
 1. `assets/`, with `cache-control: public, max-age=31536000, immutable`.
 2. `img/`, `manifest.json`, `contribute.json` and the Search Console file, one hour.
@@ -126,8 +126,8 @@ stay in the bucket because the CDN can serve a stale `index.html` for a while af
 
 The workflow then checks `version.json` straight from the bucket, waits (bounded at five minutes) for
 the public URL to serve the new bundle at the root and every route, checks an unknown path still 404s
-and the hardware dataset still answers, and finally runs the live Playwright project against the
-deployed URL as a smoke test. A failed smoke test does not undo the deploy; it flags it.
+and the hardware dataset still answers. A separate `smoke-test` job then runs the live Playwright
+project against the deployed URL. A failed smoke test does not undo the deploy; it flags it.
 
 ## How deploys have happened
 
@@ -139,7 +139,8 @@ deployed URL as a smoke test. A failed smoke test does not undo the deploy; it f
 - 2023-06 Data Engineering created the GCS buckets above and uploaded v1.2.0 to stage.
 - 2025-05-12 someone uploaded v1.2.1 to prod by hand, then the four route copies. No record of the
   commands used exists.
-- 2026-11 the GitHub Actions workflow above replaced hand uploads (WT-1916).
+- 2026-11-09 the GitHub Actions workflow above replaced hand uploads, with its first automated
+  deploy to stage from commit `fdeafe0` (#480, WT-1916).
 
 ## Open questions
 
diff --git a/docs/architecture/frontend.md b/docs/architecture/frontend.md
index cee907c..c293af2 100644
--- a/docs/architecture/frontend.md
+++ b/docs/architecture/frontend.md
@@ -25,7 +25,8 @@ call-to-action via `src/components/decorators/withNextButton.jsx`.
 ## Data flow
 
 This application has no state library, no hooks-based state, and no Redux — state lives in
-`this.state` on class-based container components, plus one `sessionStorage` key,
+`this.state` on class components (the containers, the class `withFetch` wraps them in, `Spinner`,
+and `LazyBoundary`), plus one `sessionStorage` key,
 `preferredRegion`, set in `DashboardContainer.jsx`. Three containers do all of the data fetching:
 
 | Container | Fetches | Notes |
@@ -39,8 +40,10 @@ a higher-order component: `withFetch(props => url)(Container)` fetches the URL a
 the container a `dataFetch` prop holding `pending`, `rejected`, `fulfilled`, `value`, and `reason`.
 It refetches when the URL changes, going back to pending first, treats a non-2xx response as a
 rejection, and ignores a response that arrives after a newer request has started. Each container
-handles those states itself and renders `views/Spinner.jsx` or `views/Error.jsx` accordingly. All reshaping of
-fetched data happens client-side in each container's `formatData` method — `ChartContainer` sorts
+handles those states itself: `DashboardContainer` renders `views/Spinner.jsx` while pending, the
+two metric containers render nothing (the chart's own spinner shows instead), and all three render
+`views/Error.jsx` on rejection. All reshaping of fetched data happens client-side, in the
+`formatData` method of `ChartContainer`, `DataTableContainer`, and `SummaryMetricContainer` — `ChartContainer` sorts
 its populations by maximum y-value and drops nulls; `DataTableContainer` sorts rows by value,
 descending.
 
@@ -50,7 +53,7 @@ Metric `description` strings are rendered as inline Markdown and inserted via
 `dangerouslySetInnerHTML` — React's own escape hatch for inserting raw HTML, named the way it is
 specifically to make a reader stop and check what's flowing into it. Confirmed by reading every call
 site (`grep -rn "dangerouslySetInnerHTML" src/components/`): there are exactly four, two in
-`views/Dashboard.jsx` (lines 57 and 65) and two in `views/MetricOverview.jsx` (lines 34 and 40).
+`views/Dashboard.jsx` (lines 57 and 65) and two in `views/MetricOverview.jsx` (lines 35 and 41).
 
 The two files configure their `markdown-it` parser independently of each other, not from one shared
 configuration — worth knowing before changing either, since a change to one does not affect the
@@ -63,8 +66,8 @@ file's enabled-rule list without extending that test to match.
 
 ### Security posture, as of this writing
 
-`npm audit` reports 17 vulnerabilities against a fresh install (3 moderate, 14 high, 0 critical).
-This is down from an earlier, much worse baseline of 251 (21 of them critical), confirmed at the
+`npm audit` reports no critical vulnerabilities against a fresh install; the exact count changes
+as advisories are published, so run it rather than trusting a number here. This is down from an earlier, much worse baseline of 251 (21 of them critical), confirmed at the
 time by tracing all 21 critical-severity package names through `npm ls <name>`: every one resolved
 through exactly one of four build-only dependency roots — `react-scripts`, `nightwatch`, `request`,
 or `npm-run-all` — none of which was imported by any file under `src/`, so none of them shipped to
@@ -72,36 +75,26 @@ the browser. All four have since been removed from this repository entirely (`re
 `npm-run-all` replaced, `nightwatch` and `request` no longer used at all), which is why the critical
 count is now zero.
 
-Of the advisories that do affect packages actually bundled into the shipped build, each sits behind
-a code path this application doesn't exercise: `markdown-it`'s flagged `linkify`/`smartquotes` rules
-are the ones disabled by the `zero` preset described above; a flagged `d3-color` ReDoS advisory
-needs an attacker-controlled color string, and this application has none; a flagged `react-router`
-regex advisory needs parameterized routes, and this application's four routes
-(`/`, `/contact`, `/dashboard/<key>`, and a catch-all) are all static.
+The only advisory against a package bundled into the shipped build is a `d3-color` ReDoS (pulled in
+by `metrics-graphics`'s `d3@4`). It needs an attacker-controlled color string, and this application
+has none. Every other flagged package is a build or lint tool.
 
 The one real, structural gap: **there is no Content-Security-Policy**, and the four
 `dangerouslySetInnerHTML` sites above rely entirely on `markdown-it`'s `html: false` default
 holding — true as of this writing, but not enforced by any test or header. Adding a CSP is a genuine
 piece of security work, not something this documentation pass does on its own.
 
-## Three confirmed code defects, not yet filed as issues
+## A confirmed code defect, not yet filed as an issue
 
-Found while verifying this repository's own claims about itself, and confirmed by reading the exact
-lines named:
+Found while verifying this repository's own claims about itself. Two others found at the same time
+have since been fixed (`c8422fb`, `96b5afc`).
 
-- `views/Chart.jsx` line 112 checks `props.suggestedYMax`, but line 113 reads
-  `props.suggestedMax` — a prop name that does not exist anywhere else in the codebase. This is
-  currently latent because no live metric sets a `suggestedYMax`, but it will silently produce the
-  wrong chart y-axis maximum the moment one does.
-- `views/SummaryMetric.jsx` line 46 sets `this.arrowIgnoreThreshold = 4` in the constructor, but
-  line 131 reads `this.ignoreThreshold` — a property that is never set anywhere. The "hide the
-  arrow on small bars" logic this line implements has never worked.
 - `views/SummaryMetric.jsx` line 67 defines a `_handleResize` method that is never attached to any
   event listener anywhere in the file (confirmed: no `addEventListener` call exists in it at all).
   The four hardware summary bars this component renders do not respond to window resize.
 
-None of these three are filed as GitHub issues as of this writing. Whoever picks one up should file
-it as an issue first — these are exactly the kind of finding that belongs in the tracker, not as a
+It is not filed as a GitHub issue as of this writing. Whoever picks it up should file it as an
+issue first — this is exactly the kind of finding that belongs in the tracker, not as a
 permanent list in this file, for the same reason the wider issue backlog isn't summarized in
 these architecture docs.
 
@@ -113,7 +106,7 @@ these architecture docs.
     ├── registerServiceWorker.js     only unregister() is called
     ├── setupTests.js                jest-dom matchers; fails on console.error
     ├── components/
-    │   ├── containers/              6 stateful, data-fetching .jsx files (above)
+    │   ├── containers/              6 class components; 3 fetch via withFetch (above)
     │   ├── decorators/              withTracker.jsx (GA4 via react-ga4), withNextButton.jsx
     │   └── views/                   20 presentational .jsx files
     │       ├── styl/                Stylus source, hand-edited; includes/lib.styl holds shared variables
@@ -134,7 +127,7 @@ these architecture docs.
 
 There is no `pages/`, `store/`, `hooks/`, `api/`, or `locales/` directory — this is a small enough
 application that none has been needed. `public/` holds static files served as-is (`manifest.json`,
-`contribute.json`, `img/`); `index.html` itself lives at the repository root, Vite's convention.
+`contribute.json`, `img/`, and the Google Search Console verification file); `index.html` itself lives at the repository root, Vite's convention.
 `build/` is gitignored output. Routes are exactly `/`, `/contact`, `/dashboard/<key>`, and a
 catch-all not-found page.
 
@@ -143,8 +136,8 @@ catch-all not-found page.
 Two abandoned packages used to cap React at version 16: `react-refetch`, the data layer, and
 `react-metrics-graphics`, the chart wrapper. Local replacements have taken their place:
 `src/lib/withFetch.jsx` and `views/MetricsGraphics.jsx`, which calls `MG.data_graphic` directly.
-`metrics-graphics` itself stays on 2.15.6, because its only newer release is a 3.0 beta, unpromoted
-since 2022, that rewrites the API.
+`metrics-graphics` itself stays on 2.15.6, because its only newer release is `3.0.0-beta1` from 2022,
+which npm tags `latest` but was never released as stable, and which rewrites the API.
 
 What holds the application on React 18 now is its lazy loading, not a dependency. React 19 keeps a
 `Suspense` fallback on screen for at least 300 ms before revealing what it was waiting for. A
diff --git a/public/contribute.json b/public/contribute.json
index 4097a95..2112d9a 100644
--- a/public/contribute.json
+++ b/public/contribute.json
@@ -14,15 +14,15 @@
         }
     },
     "keywords": [
-        "create-react-app",
         "css",
         "d3",
         "javascript",
-        "jest",
         "metrics-graphics",
-        "nightwatch",
         "node",
-        "react"
+        "playwright",
+        "react",
+        "vite",
+        "vitest"
     ],
     "bugs": {
         "list": "https://github.com/mozilla/ensemble/issues",
@@ -30,7 +30,7 @@
         "mentored": "https://github.com/mozilla/ensemble/labels/help%20wanted"
     },
     "urls": {
-        "stage": "https://data-ensemble.stage.mozaws.net/",
+        "stage": "https://dfc-stage.data-static-websites.nonprod.webservices.mozgcp.net/",
         "prod": "https://data.firefox.com/"
     }
 }