fix(web): un-combine the item tab strip below 560px + header slim groundwork (TASK-2329)

[xarmian]

TASK-2329 of PLAN-2326. Five commits: the original header work, a revert of the part of it that was wrong, the actual mobile fix, a boundary re-derivation + Star gating, and a comment-accuracy pass.

Body rewritten. The first version of this description documented a 700px single-fold design that Dave's review of the running build rejected as unusable on phones. That design is reverted in 8c3e0c2b and replaced in e97d7425. Nothing below describes the old approach except where it is the "before" measurement.

What was wrong

Combining the tablist and the action group on one row is not survivable at phone widths, and no amount of folding fixes it. The four tab labels are a fixed 321px; even a hypothetical action group of nothing but ⋯ (38px) needs 359px against the 342px a 390px phone has.

Measured on the widest common phone, 430px, on bd030124:

	strip	tabs need	tabs shown	clipped
430px phone	382px	321px	179px	2 of 4
390px phone	342px	321px	139px	3 of 4
360px phone	312px	321px	109px	3 of 4

…with scrollbar-width: none, so no hint the missing tabs existed.

8c3e0c2b — revert

• Saved / Synced go back inside .meta-info, byte-identical to main. Relocating them into .strip-actions pushed 115px into a strip that was already overflowing and inflated the badges (39→48, 40→50) by escaping .meta-info's 0.8em.
• .save-status:not(.visible) { display: none } reverted — measurably harmful. In a real 448px pane, toggling it moved the action group 87→143px and the tab scrollport 301→245px: a 56px reflow on every save cycle, under a hidden scrollbar.
• .collab-state-label's sr-only fold, now dead — the query container is .tab-strip and the badge no longer lives inside it.
• .meta-info { display: none } reverted for SEQUENCING, not because it was wrong. .collab-state-synced is SYNCED_BADGE_SELECTOR and five specs across four suites assert it visible. It returns once the badges have a new home.

Kept: the @media print { .title-row .item-ref { display: block } } reset — a latent-bug fix predating this PR, since main's print rule sets twelve properties and no display, so any screen-side display:none on the chip would silently drop the ref from the page-1 document header (BUG-626). Also the screen-side ref hide, the backlinks aria-label, the ⋯ Star row, and the capstone spec's strengthened assertions.

e97d7425 — the fix: un-combine below 560px

< 560       split — actions own a row, ABOVE the tabs
560 - 639   fold  — one row, badge icons → bare counts, star folds
<= 330      tab padding 11px → 8px (the last 24px needed at 312px)

Below 560 the star and the badge icons come back — the single <700 fold hid them on every phone and in the default-width docked pane, exactly the widths with the least need to economise once the actions have their own row.

Actions ABOVE the tabs (order: -1, visual only). .tab-strip owns the bottom divider and .pane-tab.on overlaps it by 1px via margin-bottom: -1px; keeping the tablist last preserves that — measured identical (offset 0) in both shapes. Actions-below would orphan the underline ~31px above the divider.

Two placement traps, both caught by measurement rather than reasoning

1. flex-wrap must be in the base .tab-strip rule, not the @container block. A container query cannot style its own query container. Verified by mutation: moved inside, nowrap stays in force while flex: 0 0 100% still applies to .strip-actions, and .pane-tabs collapses to 0px with all four tabs clipped at every phone width. Both new tests go red on it.
2. The <= 330 rule must sit after the base .pane-tab rule. Container queries add no specificity, so the selectors tie and source order decides. Written above it, the tabs kept scrollWidth: 321 inside a 312px strip and one tab stayed clipped.

Measured (worst case: both badges + quick actions + owner rights)

Desktop — must be unchanged, and is, to the pixel:

viewport	rows	header	tabs	underline
1440 / 1200	1	148.8px	fit	0
1024 / 768	1	174.8px	fit	0

Phone — tabs now fit where two to three were clipped:

width	strip	tabs (need / shown)	before
360	312	297 / 297 ✓	321 / 109, 3 clipped
390	342	321 / 321 ✓	321 / 139, 3 clipped
412	364	321 / 321 ✓	321 / 161, 3 clipped
430	382	321 / 321 ✓	321 / 179, 2 clipped

Docked pane 360 / 448 / 600 → split; 720 (PANE_WIDTH_MAX, a 672px strip) → full, after the boundary re-derivation below.

Container-query proof: a 360px pane on a 1920px viewport splits, while the full page at that same viewport stays on one row. No media query can do that.

Cost: the strip goes 33px → 67px on phones, so the header grows ~34px there. That is the trade for four reachable tabs.

Also audited: .menu-anchor gained no overflow/contain/transform/filter/clip-path/will-change ancestor at any width (walked the computed styles); the desktop ⋯ panel and the 430/360 bottom sheets own all four corners by hit-test; the arrow-key roving walk still visits exactly the four tabs in a 360px pane. Chromium reports contain: none on .tab-strip despite container-type — expected, and deliberately not "fixed" with contain: layout, which does trap the sheet's position: fixed.

2c05297f — re-derive the boundary, gate the Star row

The 699 upper boundary was measuring the wrong thing. It was derived while Saved/Synced still sat in .strip-actions, worth 115px of the group. Re-measured post-salvage on the worst-case item:

action group	width	shared row needs
folded (icons off, star off)	191px	524px
full	274px	607px
full, counts inflated to an absurd 199/199 + 999	301px	634px

So 699 was folding the star and badge icons on the two widest surfaces that fold at all — a pane dragged to its 672px max, and a 1440px page with a pane docked at 678px — both with ~65px to spare. Boundary moves to 639 (full at 640+). The 560 split boundary is measurement-backed and unchanged: the folded row needs 524px, so it carries 36px of slack.

The Star ⋯ row is now gated to exactly the fold band. It was unconditional, costing every user a permanent extra row. Now hidden by default and shown only by the same query that folds .star-btn — the affordance exists in exactly one place at every width, never zero and never two, and display: none keeps the hidden one out of the a11y tree. Verified at eight widths, both directions; the 390px case exercises the mobile BottomSheet, confirming the container query reaches into it.

Two more traps this turned up, neither visible by reading:

3. .menu-anchor :global(.strip-star-row), not a bare :global(). MenuItem's own .mi { display: flex } carries that component's scope hash and is (0,2,0); a bare global class selector is (0,1,0) and loses. Measured: the row rendered display: flex at all eight widths — symmetry broken toward showing the star twice.
4. A sub-pixel gap between the bands (Codex). Encoded as adjacent integers, a strip at 559.5px matched neither query and fell back to the full shared row. Container widths are not integers — the pane default is clamp(360px, 38%, 640px). Fixed by nesting the blocks (fold ⊃ split, with the split un-folding) and using .99 bounds. Verified by forcing the strip to 559.50 / 559.99 / 560.50 / 639.50 / 639.99 / 640.50: all six now correct, four were wrong before. Regression test added — it is the only one that produces fractional widths.

That is four specificity/order/precision traps in one small block of container queries. Container queries add no specificity, and their bounds are not integers; every rule here had to be checked against what it overrides.

Slow drag through the boundaries: 563 → 688px in 5px steps produced exactly three distinct states across 27 samples — split (strip 515, 67px tall, star shown) → fold at strip 560 (33px, star folded) → full at strip 640 (33px, star shown). Tabs fit in every sample. Deliberate, not glitchy.

Tests

pane-tab-strip-tiers.spec.ts rewritten — its old "strip stays ONE row" assertion contradicted this design, and its worst-case test asserted the mechanism ("every tab reachable via scroll") rather than the outcome, which stayed true and useless at a 94px scrollport with no scrollbar. Five tests now, all asserting outcomes: the container-driven split at a fixed viewport, the 360px worst case asserting tabs fit, the fold band, the sub-pixel boundary guard, and Star-affordance symmetry across four widths.

pane-full-page-capstone.spec.ts star assertions strengthened (DR-11): toBeEnabled() requires attached, not visible, so a CSS fold would leave them green while asserting nothing.

Gates

• cd web && npm run check — 0 errors, 6 pre-existing warnings
• make check — Go tests all ok, govulncheck "No vulnerabilities found", svelte-check 0 errors, 490/490 web unit tests
• make install + Playwright measurement on every surface above, both themes
• Tier spec 5/5, capstone 8/8; full e2e 81 passed with one cross-spec flake per run — pane-collab-teardown:137 on one run, pane-content-link-anchors:238 on the next, a different test each time and both green in isolation. That is BUG-2334's shared-instance toast interference, not a regression.
• Codex review: CLEAN

Currently draft only because it was requested mid-review; the reviewer has since said non-draft is fine. Flipping draft→ready is left to the reviewer. Refs TASK-2329, PLAN-2326.

Star affordance — verified at the accessibility-tree level

display: none removing the row from the a11y tree was an assertion worth proving rather than stating. ariaSnapshot() with the ⋯ open:

• 390px phone (split, bottom sheet) — menuitems: Dependency graph, Move to collection…, Share…, Delete…. No Star. The row is in the sheet's DOM but display: none, so a querySelectorAll hit is not evidence it is announced.
• 620px pane (fold, anchored panel) — menuitems include menuitem "Star", and clicking it really stars: chip.starred false → true, title Star → Unstar, row label ☆ Star → ★ Unstar.

Announced in exactly one tier.

Containment audit — corrected

An earlier claim of "zero risky ancestors" was wrong: that probe excluded auto and stopped walking at .item-page. Re-audited to <html>, there are five pre-existing overflow ancestors (.item-page, .item-page-host, .main-content, .app-shell, .app-layout). None is a problem — overflow forms no containing block for position: fixed.

container-type: inline-size reads as unsafe in the containment spec (layout containment is specified to form a fixed containing block). Chromium does not apply that: a position: fixed; inset: 0 probe injected as a real child of .tab-strip at a 390px viewport laid out 390×844 (full viewport), not 342×67 (the strip). contain: layout does collapse it — hence the standing warning not to add it.