fix(report): remove type/spacing steps at widths the layout does not change

[scheemunai]

report changed its typographic system at two widths where nothing about the layout moved.

boundary	what stepped	column count changes?	verdict
480→481	type scale and spacing, +414px height	no	defect
768→769	spacing only, +80px height	no	defect
704→705	layout (.lede stacks, .quarter becomes a row)	yes	legitimate
1023→1024	layout (gutter)	yes	legitimate

What changed

Route 1 (fluid) for everything with a unit. Font sizes ramp across 480–768 so there is no step to misplace — body 15→17px, .lede__lead/.pull 16→19px, .sec h2/.next h2 22→24px. The three spacing values that stepped at 769 (body padding, .paper padding, .byline gap) ramp across 704–1024 the same way.

Route 2 (move to a layout boundary) for what cannot ramp. A unitless line-height has no fluid form, and an em one changes what descendants inherit — so leading and border-radius move into the 44rem block, which already declares layout.

Moving that step down widens the band it governs, from 320–480 to 320–704. So body leading lands on 1.5 exactly rather than the 1.48/1.42 it previously took below 481px — prose must not sit under the WCAG 1.4.12 floor across the wider band. This is a small improvement on the status quo at 320–480. .title keeps 1.14 as display type.

Four media blocks become two, both declaring layout.

Verification

Measured over 1601 widths (320–1920, 1px), innerWidth asserted before every recorded value:

• 480→481: +414px → 0px
• 768→769: +80px → +1px
• Steps ≥40px: six before, four after. The two remaining non-boundary steps (425, 476) are natural text-rewrap points, not declared boundaries; 704 and 1024 both change column count.
• Heights 390/768/1440: 2823/2662/2660 → 2784/2662/2660 — one better, two unchanged.
• No horizontal overflow at any of the 1601 widths.
• Type floors hold at every width (prose 13px, short 12px, uppercase labels 11px) — unchanged from before.
• Rendered text byte-identical, 3132 chars before and after. Nothing came out.
• 14,454 bytes / 18,432 cap.
• pnpm check: 20 warnings, all pre-existing, zero in report.html. pnpm exec vitest run: 1096 passed, 0 failed.

Note on the instrument

My first harness reported layout-changes=yes at every boundary, including 768→769 where no rule fires — it was comparing grid-template-columns used pixel widths, which differ at every viewport, instead of track count. That produced false exclusions, the dangerous direction. Fixed, and confirmed against the known baseline: it now independently reproduces report 480→481 at +414 with identical column count → defect.

Co-Authored-By: CRHQ noreply@crhq.ai