PCB-MVP-0 slice 2b: read a 2D extent in the frame's unit

[gunbai-bot]

Stacked on #8206. This is the residue that PR declared, and narrowing it turned out to be most of the work.

The geometry carriers are scale-agnostic. A rectangle holds signed components and never commits to what they measure, so the millimetre commitment lived entirely in the READERS — which were correct only because every frame in the corpus happened to be a millimetre frame. That makes the guard far smaller than expected: the constructors, the containment tests, the overlap logic and the whole 3D box surface are untouched.

segment2_length / rectangle2_width / rectangle2_height now return FrameExtent, read in the unit the shape's own frame was registered with. An unregistered frame refuses rather than falling back to millimetres, which would answer a plausible number for a real question. The millimetre answer is still available and is now derived through frame_length_as_millimeter, which refuses when the frame is not a millimetre frame instead of truncating into one.

The old readers are deleted rather than kept beside the new ones. A reader that asserts a unit and a reader that derives it are two answers to one question, and the asserting one is the one that was wrong.

BLAST RADIUS: one file. Only the geometry witness consumed these three. Its existing assertions pass unchanged once the two frames it draws in are registered as millimetre frames — the fact they always relied on and never stated.

The two NEW tests are the ones that discriminate, because every migrated assertion passes in both worlds. The same rectangle carrier in a micrometre-registered board frame is a 20000 um package body: the old reader called that 20000 millimetres, a twenty-metre chip. And an unregistered frame refuses to be measured at all.

RESIDUE, still declared rather than left to be found: prism3_height and the SquareMillimeter / CubicMillimeter surface across orthogonal_topology continue to assert millimetres. The 2D surface is what a board footprint needs and is what moved here. Area and volume are a larger change because their scale relationship is squared and cubed, and they have real consumers in the rack and room stack.

[gunbai-bot]

Review 51493 — fixed, and the finding is correct by this witness file's own stated rule that every negative control has a positive sibling. I wrote the rule into the file and then broke it in the test that carries the slice's whole claim.

The test asserted only that frame_length_as_millimeter refuses on a micrometre-registered board frame. Every wrong answer satisfies that — a reader returning 200 instead of 20000 passes it — so the reader's actual deliverable, returning the extent in the frame's registered unit, was never witnessed. The refusal was the easy half and it was doing all the work.

The micrometre projection is now asserted first and by count, then the millimetre refusal, so the test carries both halves in the order the comment above it always claimed.

Verified by mutation rather than by reading it back: perturbing the expected 20000 to 200 turns the test red, restoring it turns it green. That is the check I should have run before asking for review, given it is exactly the fixture-echo class I have been fixing elsewhere in this stack.

[gunbai-bot]

Consolidated into #8214 at the operator's request. These four were a linear stack and the tip branch already contained every commit from all of them, so nothing is lost by closing here — the same commits are in #8214, now based on main.

Worth stating the cost plainly rather than letting it pass silently: this discards the approval tally these PRs accumulated. The combined diff is a different subject from any one slice and needs reviewing as one, so those approvals were not transferable in any case.

Closing this one; review continues on #8214.