wdio7: four magic-time specs lack the .mtime marker, so --parallel can race the global test clock

The tyd e2e runner decides which specs may run concurrently purely from the .mtime filename marker: specs so named get run with --not-parallel, everything else is eligible for the parallel batch under --parallel N (s/impl/tyd-e2e-tests.ts, the grouping around lines 273–285).

But four specs in tests/e2e-wdio7/specs/ advance the server-global test clock without carrying the marker:

• alias-anons-approve-review.2br.f.e2e.ts
• bookmarks-basic.2br.f.e2e.ts
• modn-ban-spammer.2br.f.e2e.ts
• modn-review-specific-user.3br.f.e2e.ts

Each calls adminArea.review.playTimePastUndo(), which under the hood does server.playTimeSeconds(c.ReviewDecisionUndoTimoutSeconds + 10) (tests/e2e-wdio7/utils/ty-e2e-test-browser.ts:10293–10296) — i.e. it shifts the one server-wide test clock that every concurrently running spec observes.

Impact: under --parallel N these four land in the parallel batch, and a clock jump underneath an unrelated spec can expire sessions, skip review-undo windows, or skew notification timing — scheduling-dependent flaky failures. This is exactly the failure mode the existing TODO warns about (s/impl/tyd-e2e-tests.ts:241: "Don't run magic time tests in parallel — they mess up the time for each other.")

For contrast, the old wdio 6 suite has zero drift: its 25 clock-moving specs are exactly the 25 .mtime-named ones (verified by grepping spec bodies for playTime/pauseServerAndBrowsers and diffing against filenames).

Suggested fix — either:

1. rename the four files to include .mtime (cheapest), or
2. stop trusting filenames alone: when partitioning, grep spec bodies for playTime — that also protects against future drift, since playTimePastUndo() is easy to call without thinking of the filename convention.

Found while analyzing how many e2e specs can run in parallel, at v1.2026.003: How many of the e2e tests could run in parallel?