test(channels): discover the hoverable width for activity corners

[kalvinnchau]

Summary

• The channel activity corners journey hardcoded a 640px viewport, which sits below the 650px breakpoint introduced in fix(sidenav): align indicators and preserve width across Settings #371 that folds the sidebar into the navigation drawer. The channel trigger existed but was not hoverable, so alpha.hover() timed out on main.
• Instead of pinning a width just above the breakpoint, the test now binary-searches for the narrowest viewport where the trigger still renders client rects, then uses that boundary for the enlarged-text geometry matrix and the short-viewport scroll case. If the drawer breakpoint moves, the test follows it rather than silently landing inside the drawer.

Browser cases

• No browser cases added or removed; one journey file changed in place.

Validation

• playwright test --project chromium --grep "channel activity corners": both single-row and multiple-row variants pass locally (4.5s / 4.2s), previously timing out at 10s on main.
• Deferred: WebKit run (CI covers it); the change is engine-agnostic geometry probing.

Follows the review checklist. Agent testing exercised the changed behavior (the journey run above); human testing is available via pnpm test:browser --project chromium --grep 'channel activity corners'. Add buzz-review-completed once reviewed.

[wesbillman]

Star Lord — automated source review via Wes’s account

No actionable findings in this revision. The bounded test-only change meets the 9/10 minimalness, elegance and correctness bar for its stated purpose; this is a comment, not approval or merge authorization.

• Head: 1d50deeaed0d482f77c43c42d7f65fe93498b387
• Base: a94f88de8b3c69de0f0ced790f7468d16e1cc38a

Source assessment

The binary search in tests/browser/channel-activity-corners.spec.mjs:30–43 matches this revision’s CSS-driven visibility boundary: src/shared/styles/globals.css:238–264 hides the closed navigation drawer at widths ≤650px. Reading client rects after resizing probes that layout directly; the subsequent real hover still verifies interaction. Both existing cases retain light/dark, wide/narrow, 200% text, inset radii, short-viewport scrolling, Escape dismissal and keyboard thread-opening coverage. No cases were added/removed, tolerances relaxed, or production files changed. Real clipping/layout remains appropriate browser-only coverage.

I also traced the popover and sidebar call paths. Success/cancel assertions remain intact; error/retry focus behavior is unchanged and is not established by this geometry journey. The public description, sole commit metadata and changed source showed no actionable disclosure issue; the description contains no attached images.

Existing CI evidence and limits

Read-only snapshot of run 36603885734: artifacts record clean synthetic merge 0958ff0c71f63d0f49c32975c95a1fc0ab40f4a9, whose tree equals the reviewed head’s tree (224de944f6fd8bdc7cdc564c1ca753335b7c29a3). Both corner cases passed without retries in both Chromium and WebKit; their screenshots include the discovered 651px boundary.

Shard 3 evidence	Chromium	WebKit
Cases passed	75/75	75/75
Runner elapsed wall time	197.24s	214.33s
Summed test execution	333.78s	356.64s
Changed file, summed execution	18.43s	22.43s

The slowest shard-3 test was the history-loading remount case (14.69s / 13.98s); the workflows journey was the slowest file (80.01s / 91.78s). The WebKit corner case reached 13.00s. These hosted measurements are not comparable before/after performance evidence; the description’s 4.5s/4.2s timings are author-reported local results.

Overall CI is red: WebKit’s menu-dismiss.spec.mjs:50 failed its held-condition assertion, and the measurements lane’s WebKit scroll.spec.mjs:97 failed at line 155 (650px displacement versus <4px). Both are outside the changed file; this review does not establish they are pre-existing or flaky.

I executed no PR code, tests, builds or app. Existing hosted artifacts do not establish native behavior, repeated-run stability, or human acceptance. Those gaps and the failing required CI remain unresolved; no readiness attestation is made.