Stabilize recurring E2E shard-3 diary flakes blocking main promotions

[steilerDev]

Problem

E2E shard 3/16 (desktop) failed on both main-targeted PRs during the v2.12.0 release (promotion #1791 and hotfix #1828). The hotfix PR changed only package.json/package-lock.json (a dev-only dependency override), so these failures are definitively flakes, not regressions. Because main PRs run with fail-fast (maxFailures: 1), a single shard-3 flake cancels all other shards and costs a full ~30-minute rerun cycle per occurrence.

Failing tests (from run 28779550395, job 85332065279)

1. e2e/tests/diary/diary-drafts.spec.ts:854 — "Draft card click navigates to edit page (Scenario 14)"
   Error: apiRequestContext.delete: Test timeout of 45000ms exceeded. (fails on first attempt AND retry EPIC-01: Authentication & User Management #1, 48s each)
2. e2e/tests/diary/diary-r2-uat.spec.ts:599 — "Manual mode API parameter (Scenario 10)" (fails in 942ms — assertion, not timeout)
3. e2e/tests/documents/document-linking.spec.ts:369 — "System-wide Hide (Scenario 7) — toggle defaults ON and hides linked doc @Responsive"

History

These same diary tests were addressed in #1790, #1792, and #1793 but still recur. The dominant signature is the fixture teardown apiRequestContext.delete timing out at 45s — suggesting cleanup contention/deadlock under parallel CI load rather than a UI assertion problem.

Acceptance criteria

• Root-cause the apiRequestContext.delete 45s timeout in diary-drafts fixture teardown (e.g. SQLite write contention under parallel workers, dangling request queue)
• Fix or quarantine-and-fix the three tests above so 5 consecutive full E2E runs on a main-targeted PR pass without a shard-3 rerun
• Consider whether fail-fast (maxFailures: 1) should tolerate one retry-passing test before cancelling all shards

[orchestrator] Filed during v2.12.0 /release post-merge verification; both occurrences today recovered via gh run rerun --failed.

[steilerDev]

[orchestrator] Resolved in PR #1855 (squash-merged to beta). Root cause: only ONE of the three cited tests was a genuine trigger — diary-drafts Scenario 14 paired a 45s overall budget (test.slow() does NOT triple step timeouts) with 30–45s per-step waits, starving the teardown delete (the reported apiRequestContext.delete timeout was the symptom, not the cause). Fixed with explicit 60s budget, proportionate step ceilings, and a guaranteed-cleanup-headroom pattern. diary-r2-uat Scenario 10 was a separate mock-response race (now per-transition waitForResponse); document-linking was pure fail-fast collateral. The maxFailures acceptance item was already satisfied — Playwright only counts post-retry failures (verified in dispatcher source, now documented in the config). On this PR's own run, all three tests passed on shard 3 in 1–2s. The 5-consecutive-runs criterion is validated over subsequent CI runs. NEW pre-existing flake flagged for follow-up: household-item-detail.spec.ts:141 failing across all 3 viewports repeatedly in recent runs.

[github-actions]

🎉 This issue has been resolved in version 2.13.0-beta.24 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀