Let the edge trim reach the live tab block's bottom margin

[leaf-agent]

Problem

ci on main is red at fcf32c2: tests/test_render_gate.py::test_example_renders fails on both gallery and parallel-workstreams with <main> draws 96px of inset and shows 128px below what it holds … its last block is a <lf-tabs> reserving 32px against a neighbour it hasn't got.

ce73388 gave a rendered lf-tabs its own frame and stated the block margin around it in the same rule — inside @media screen { html:not(.lf-copy) { … } }. That guard carries weight: the nested selector is html:not(.lf-copy) lf-tabs.lf-rendered, and the edge trim in theme.css is :nth-last-child(1 of :not(.lf-ui, [data-lf-gen])), which the guard outranks. main declares --lf-frame: 1, so on a page whose column ends in a tabs block the trim fired and lost, and the 32px it should have cancelled was painted as page inset — the exact reading TRAPPED_MARGINS exists to report.

Solution

Make the guard weigh nothing: :where(html:not(.lf-copy)). Every rule in the block then says what it weighs on its own, the tabs margin drops to lf-tabs.lf-rendered (0,1,1), and the trim reaches it.

:where(html:not(.lf-copy)) is already the file's idiom for a medium guard that shouldn't add weight — seven other blocks in packages/default/theme.css use it, and the one nested rule that needs weight against a :not() chain (lf-options[choose] at line 468) states it separately. The fix is at the level of the rule the regression is in rather than at the trim, because a trim that had to outrank whatever a widget declares would be an !important in a stylesheet a project overlays.

What the other rules in the block do at their own weight

Checked each against what it has to beat, since the guard's weight came off all of them:

rule	new weight	contest
lf-tabs.lf-rendered	(0,1,1)	beats lf-tabs (0,0,1); now loses to the trim (0,2,0), which is the fix
.lf-tabstrip	(0,1,0)	ties .lf-tabstrip { display: none } 20 lines above and wins on source order
> lf-tab::before	(0,1,2)	beats lf-tab::before (0,0,2)
> lf-tab	(0,1,2)	ties lf-tabs.lf-rendered > lf-tab { margin-top: 14px } and wins on source order
> lf-tab:not([hidden]), [hidden], [hidden]:not(…)	(0,2,2)–(0,3,2)	unchanged relative order

tests/test_render_navigation.py::test_an_inline_tab_keeps_its_panel_inside_one_visible_boundary — ce73388's own test for the frame, its grounds and its insets — passes, so the surface ce73388 built is intact.

Testing

• uv run pytest "tests/test_render_gate.py::test_example_renders[parallel-workstreams]" "tests/test_render_gate.py::test_example_renders[gallery]" --run-nightly -n0 — 2 passed; both fail on main without this change (reproduced here first).
• uv run pytest tests/test_render_navigation.py tests/test_render_gate.py --run-nightly — 120 passed.
• uv run pytest tests/test_interact_layer.py — 125 passed, 6 skipped.
• pre-commit run --files plugins/leaf/skills/leaf/packages/default/theme.css — clean.

The run's two other failures are separate and not in this PR: the search-match bounding_box() read is #111, and test_every_ring_the_layer_draws_is_shown_whole_somewhere_in_the_corpus reports the page-map preview's close button sitting over the find box's ring in design mode, which is its own defect.

---

Automated fix for failed run

[leaf-agent]

Still failing on main one commit later: 33273880881 at e5e3063, with the same two readings this PR fixes — tests/test_render_gate.py::test_example_renders on both gallery and parallel-workstreams, each reporting <main> draws 96px of inset and shows 128px below what it holds … its last block is a <lf-tabs> reserving 32px against a neighbour it hasn't got.

e5e3063 touches notes/agent-usability-evals.md alone (4 insertions, 4 deletions), so it carries nothing that could reach the cascade — the failure is inherited from main, as this PR's diagnosis of ce73388 says.

The run's third failure is the find-box ring under the margin preview's close button, which is #114.

[leaf-agent]

The third failure this body flags as "its own defect" now has a PR: #114, which takes placePreview's room from the page's box instead of the window. Independently derived the same two fixes from 33272397619 (d2fa10f) before finding these, and the pair is jointly sufficient — with both applied, uv run pytest tests --run-nightly is 1493 passed, 6 skipped in 30:01. Nothing else in the run is red, so #113 and #114 together close it and no third change is owed.

Base for that run was d2fa10f plus both diffs, not today's main (049f5df), which has moved four commits since; the suite has not been run against that head with both applied.

Same conclusions, reached separately

• The trapped margin is cascade, not a missing declaration: main computes --lf-frame: 1 and lf-tabs.lf-rendered is genuinely the :nth-last-child(1 of :not(.lf-ui, [data-lf-gen])) match — probed in the browser, it just computes margin-bottom: 32px anyway. :where() on the guard is the same change as this PR's.
• For the preview, measured on gallery in design mode at 1200×900 with Threads open: marker 589–621, card 629–949, panel 780–1200, page box 0–765. rightRoom reads 1200 - 621 - 12 = 567 against a 328px need, so the card goes right and 169px of it lands on the panel; against the page's box it is 132, so it flips left to 261–581.
• Both first appear at ce73388 — 33269374595 on c14bb42 has neither.

One difference worth naming, though it is not a defect in #114: document.body.getBoundingClientRect().right is body's border-box edge, which includes the scroller's stable gutter, where composing/surface.js's rightEdge() uses pageScroller.clientWidth and stops inside it. The card can therefore sit up to a gutter's width under the scrollbar. A fixed float cannot hand body a sideways scrollbar, which is what that clamp in surface.js is for, so the looser bound is defensible — just not quite the same reading.