Close out PR #2143: prlanded record and two captured follow-ups

docs/branch-review-records/fe3fb93648dc52663a4c8f62e9b80f79a95e3d30e9205c2e1a8423cd888abc24.record.md

@@ -0,0 +1 @@
+| 2026-08-18 | claude/header-redesign-mockups-3ms5kn | 333399f7f5ebfb83c304bf7a0bbdbd71b6849238 | prlanded | landed clean | git diff --stat 333399f 6bd0934 empty (squash tree identical to branch tip); browse header, dictionaryBrowseLetter, new test and both mockup studies verified present on origin/main; no commits orphaned by the merge |

docs/outstanding-issues-inbox/1b3f0964-1cf4-4fad-b89d-b9393797807a.json

@@ -0,0 +1,14 @@
+{
+ "version": 2,
+ "id": "1b3f0964-1cf4-4fad-b89d-b9393797807a",
+ "createdOn": "2026-08-18",
+ "action": "add",
+ "payload": {
+ "pri": "P2",
+ "type": "issue",
+ "summary": "Repeated main-merges on open PR branches cancel required CI, so 'PR required' reads red with zero failing jobs",
+ "detail": "PR #2143 went red on five consecutive heads and was merged past it. Job logs for runs 32170524256 (first) and 32178668323 (last) both report 'CANCELLED with no failing job' and zero failures: the first cancelled only lighthouse-budget while UI_FAST_RESULT and UI_RESULT were success; the last cancelled static-pr, coverage, production-ui-critical, production-ui and lighthouse-budget. Cause is cancel-in-progress firing on each new head, and something merged origin/main into that branch roughly every five minutes during a single working session, minting a head each time. #095 deliberately keeps a cancelled required job RED, which is correct, so the defect is the churn producing the heads, not the aggregate. Consequence beyond noise: the red is indistinguishable at a glance from a real break, and this PR was merged with it red. Next step is to find what is auto-syncing open PR branches (AGENTS.md 'Open PR branch sync (anti-churn)' says sync:pr-branches:apply is operator-run and should be late and once) and make it stop re-syncing a branch whose required CI is in flight. Related to #CCZ4HB, which records the same churn exhausting the review-bot budget.",
+ "source": "PR #2143, runs 32170524256 and 32178668323, 2026-08-18",
+ "issueUlid": "01M0BEKPPPTF6TPJJMJ4WW5KWJ"
+ }
+}

docs/outstanding-issues-inbox/83bc6aa5-e316-4524-bda8-458cea816f7a.json

@@ -0,0 +1,14 @@
+{
+ "version": 2,
+ "id": "83bc6aa5-e316-4524-bda8-458cea816f7a",
+ "createdOn": "2026-08-18",
+ "action": "add",
+ "payload": {
+ "pri": "P3",
+ "type": "task",
+ "summary": "Phone screenshots and DOM measurements taken before the phone chrome stack settles misreport every offset below it",
+ "detail": "The phone header stack (.phone-sticky-header-stack) is position:fixed and mounts collapsed, and the page reserve max-sm:pt-[var(--phone-overlay-chrome-h)] resolves to the settled height only after mount. A Playwright screenshot or evaluate() run at networkidle can therefore read main at y=72 with the mode-nav rail overlapping it, when the settled layout has main at y=121 with no overlap at all. Measured on /dictionary/browse 2026-08-18: unsettled h1 y=88 (appears hidden behind the rail), settled y=161, and the same page before and after a header redesign both settled to y=161 — i.e. the apparent overlap was pure measurement artefact. This cost a wrong diagnosis and a reverted 'fix' that padded the header to clear a rail that was never covering it. Fix is a documented settle wait (waitForTimeout ~1200ms, or better a wait on the stack's settled height) in the phone verification recipe in docs/testing.md, so the next person measuring phone chrome does not repeat it. Cheap, docs-only.",
+ "source": "Dictionary browse header rebuild, PR #2143, 2026-08-18",
+ "issueUlid": "01M0BEKZWBXPY409BJF44CPRF0"
+ }
+}