fix(frontend): the reduced-motion preference reaches the page

[ExtraToast]

Why

playwright.config.ts asks every project but the motion one to run as a visitor who asked for
reduced motion, and says so in a comment. That never happened. The option was ignored by the
runner-managed context, so the reduced-motion path had never been exercised by an end-to-end
test, in any project, and the suites that were meant to be deterministic ran with the full
choreography playing.

closes #852

What this achieves

The preference reaches the page, so the comment is true and the reduced-motion path is exercised
by every test rather than by none. The suite also runs in roughly half the time, which is the
choreography no longer playing.

How

An upgrade, not a workaround. The bug is upstream and long-standing rather than a regression:
probed across releases, the preference fails to reach the page on 1.55.1, 1.56.1, 1.57.0, 1.58.2,
1.59.1, 1.60.0, 1.61.1 and 1.62.1, and works on 1.63.0 — microsoft/playwright#42001, closed on
30 July, milestone v1.63. Emulating it ourselves would have put a workaround in every spec for a
bug the vendor has already fixed, and left the config's comment still lying.

The dependabot hold at >= 1.61 goes with it. It cited Yarn PnP, which this package left for the
node-modules linker.

Not in scope

The system tests pin com.microsoft.playwright:playwright separately, with their own driver and
browsers, and never set this option — untouched. CI installs browsers from the lockfile, so there
is no second version to bump.

Worth a reviewer's attention

Merge #1148 first. This branch is stacked on it. With that change reverted and this upgrade in
place, boards-swipe.motion.spec.ts:176 fails 3 times out of 3 on Received: 0 — the newer
Chromium exposes a pre-existing race in a test helper, which #1148 fixes on its own terms.

Two emulateMedia calls went; four stayed, and their comments were wrong. The four in the
motion project carried comments saying they should be deleted once this issue was fixed. Doing
that would have deleted the coverage: that project asks for no preference on purpose, so a
reduced-motion case living there has to set the preference itself. Their comments now give that
reason. The two that genuinely were working around this bug — in esports-season-on-show and
membership — are gone.

A handful of other #852 mentions elsewhere in the specs are now stale, including one that
repeats the same wrong instruction. Left alone here rather than widened into unrelated files; worth
a follow-up.

Nothing else broke. Making the preference real changes the whole suite's behaviour at once, so
the fallout was measured rather than assumed: 820 passed before, 820 passed after, zero specs
needed changing.

Verification

Full yarn test:e2e stacked on #1148: exit 0, 820 passed, 0 failed, 36 skipped, down from 4.7
minutes to 2.8. yarn typecheck, yarn lint and yarn test:unit (1540 tests) all exit 0.

Confirmed after the upgrade that testInfo.project.use.reducedMotion and the page now agree:
resolved=reduce inPage=true, in both chromium and mobile-chrome.

---

Diff breakdown — █ added ░ removed, scaled to the largest row.

frontend                                            +7    -25    5
  e2e tests          █████░░░░░░░░░░░░░░░░░░░░░     +6    -24    4
  build & config     █░                             +1     -1    1
  generated          ███████░░░░░░░░░░░░░░░░░░░    +15    -38    1  ~

ci                                                  +0     -8    1
  build & config     ░░░░░░░                        +0     -8    1

──────────────────────────────────────────────────────────────────
production                                          +0     -0
tests                                               +6    -24
total (hand-written)                                +7    -33  6 files
~ generated (excluded)                             +15    -38  1 file