test(e2e): the app-ready report says where the boot time went (#305 diagnostics)

[MerciHanrim]

Summary

Part of #305: the app-ready failure report now says where the boot's time went, so the next real CI failure brings its own evidence. Test code only: the readiness condition (the toolbar, then the canvas, each visible), the 8 s budget and the retry policy are unchanged, and nothing reaches a product bundle.

The intermittent stall has not been reproduced: 51 local cold starts (up to 8x renderer CPU throttling) and 30 cold starts in one targeted run on the CI runner, all under 4.6 s. The measurements are recorded on #305; its cause is not established, and #305 stays open.

What changes

• A boot trace in every watched document (e2e/support/appReady.ts, bootTrace, an init script registered on every context the shared fixture sees). Compact so it cannot slow the boot it measures: one check per animation frame (no subtree observer); the first time <html lang> is set, #root gets a child, the toolbar is attached and visible, the canvas is visible; the frame count and the longest frame gap; a running count, sum and top three of the long tasks; the CJK punctuation faces' states. It stops 500 ms after the canvas is visible. Requests are not recorded one by one; the resource-timing buffer is raised from 250 to 2,000 entries, since the dev build loads about 270 modules.
• Two clocks, kept apart in the report. Node's: the navigation, DOMContentLoaded and load events, the toolbar during the wait and the verdict, in ms from the wait's start. The renderer's: its marks and work, in ms from its navigation start, with the wait's start placed on that clock; and the browser's own navigation and resource timing read once: the request count, the catalog requests and the single slowest request, its query values masked.
• A late trace. When the renderer misses the 1 s probe at the deadline, the same read is collected when it answers, at most 5 s after the verdict, so the verdict is unchanged; the report says whether it answered and what state the boot was in by then.
• watchContext is now awaited by the fixture, so the trace is registered before a page navigates.

Unchanged

The readiness condition, toBeVisible with the project's 8 s expect timeout, the retry policy, the Playwright configuration, product code, version, release notes and change declarations.

Tests

• e2e/app-ready-diagnostics.spec.ts +4: the Node and renderer timelines, each with its own marks; a renderer held busy for 2.5 s at the deadline and its late trace carrying that long task; the slowest request named with its query value masked and requests not listed one by one; a document without a trace.
• Test list: chromium 1,972 → 1,976 (+4), mobile 117 and portable 16 unchanged, so the default projects 2,105 → 2,109; dist 16 and PWA 19 unchanged; no title renamed or removed.

Checks run locally

• npx tsc -b, unit tests 3,465 passed, every source check:* (25), oxlint at its 39-warning baseline; check:e2e-shards: every one of the 2,109 listed tests in exactly one of 6 shards, each within the budget.
• app-ready-diagnostics, i18n-zh-hans and whats-new (the two specs of the PR feat(diagram): grid-aligned editing, automatic orthogonal routing, editable connection shapes, text inside node outlines and re-placed Templates (v0.25.0) #345 failures), chromium, 1 worker, retries 0: 118 passed.
• No full local e2e; the full regression is this PR's CI.

[cloudflare-workers-and-pages]

Deploying cozy-loop-studio with    Cloudflare Pages

Latest commit:	17c7748
Status:	✅  Deploy successful!
Preview URL:	https://09dd577e.cozy-loop-studio.pages.dev
Branch Preview URL:	https://fix-app-ready-305.cozy-loop-studio.pages.dev

View logs