docs: line-box fidelity - no uniform correction is safe (measured negative)

[owjs3901]

Why

The mobile-width gap (landing 360px at 11.41% against 1920px at 1.84%) was localized in #36 to cumulative vertical drift through HUG parents. This task attempted the correction. It found that no uniform correction is safe, and lands that as a measured result rather than shipping a change that moves the error around.

No crates/ file, no threshold, no golden, no checksum, no diagnostic and no source map changed. One document.

The three corrections, all rejected

probe	360px	992px	1920px
baseline	11.41	3.10	1.84
whole-pixel token line boxes	9.64	3.71	2.31
all HUG text height correction	10.03	3.95	2.42
multiline HUG correction	10.35	3.81	2.31

Every probe improves the narrowest width and regresses both wider ones. Trading 0.60–0.84pp at 992 and 1920 for 1.77pp at 360 would leave the repo worse at the two widths currently closest to the design, so the no-regression condition rejected all three.

Why it is not a tuning problem

The same heading measures +1.953px too tall at 360 (design 245, browser 246.953) and −1.625px too short at 992 and 1920 (design 272, browser 270.375). The sign reverses with width.

No single uniform per-line correction can satisfy both signs at once — it must worsen one while improving the other. The three probes sharing one signature was that proof arriving three times, not three unrelated failures.

The sharpest datum

Reading the design's own PNG rather than inferring from node heights:

Figma PNG   Zero glyph bands begin  y 101 / 150 / 199   (advances 49, 49)
browser     same bands begin        y 101 / 150 / 200   (advances 49, 50)

The first two lines agree and the third starts one pixel late. That is consistent with half-leading or ascent/descent differing on accumulation, not with a wrong ratio. The document states which of those the numbers can and cannot distinguish, and deliberately does not claim a universal pixel-advance rule from three screenshots.

PERCENT normalization is closed out

Figma reports lineHeight as {unit: PERCENT, value: 129.99999523162842}. line_height() already rounds that to 1.3, matching the plugin's own Math.round(v/10)/10. Using the unrounded value changes the per-line advance by under two millionths of a pixel, so that rounding is not the residual. Direction 2 of the brief is answered with evidence rather than a change.

Separate gate defect found

devup-mcp --test cli's version_build_id_reports_the_repository_dirty_state failed once during this work (left: false, right: true): the binary was compiled while the tree was clean at 9f287d34e4b1, then untracked probe files appeared, so the compiled-in identity said clean while the runtime git status --porcelain=v1 --untracked-files=normal saw dirty. Documented under its own heading with the mechanism; not fixed here, as it deserves its own change.

Verification

Coordinator-measured on the merged branch: cargo fmt --all -- --check exit 0; cargo test --workspace 1049 passed / 0 failed / 2 ignored (99 suites); working tree clean so the identity race does not fire. Identical to before, which is the correct outcome for a change that touches no code.

Docs only; no changepack applies.