Fix the stacked-structure geometry the census could not yet see

[P4suta]

Two coordinates inside a warichu block were the last places the three reference engines
did not agree, and both are one reading of §3.4.2 that
docs/decisions/stacked-structure-geometry.md
turned on but never spelled out: a note's sublines run beside the line, and the block
they make is one position on it.

Fixes #23
Fixes #24

What was wrong

The block axis (#23). engines/racket/compose.rkt reported a line's block_extent
as the sum of the note's own subline heights wherever that was larger than the
paragraph's own block size. A note set at the paragraph's em rather than at the half em
§3.4.2's own sizing comes to therefore made the line twice as deep as the paragraph set
it, as though the two sublines were two lines of the paragraph.

(abcd) full-em, warichu [0,6), eight-em measure
before  (4000/2000)   after  (4000/1000)   ← Rust and OCaml, byte for byte

The boundary inside a subline (#24). A member reported its bare body as its advance,
so a member standing before a Table 1 amount inside its own row — cl-02 then cl-01,
half of the note's own em — reported 500 while the same engine placed the next member 750
units on. The answer's own advances did not reach the answer's own positions.

※〉〈あ※ half-em note, warichu [3,12), six-em measure
before  [... 1000:0+500 1750:0+500 ...]   after  [... 1000:0+750 1750:0+500 ...]

§3.8.3's half of the same reading. raw-gap-terms handed the reduction ladder every
interior boundary at face value, the block's own included, so a line that could not fit a
note squeezed the note's interior instead of overrunning — and gave back space that was
never on the line. The expansion ladder already stopped at a block, through
same-complex?; both now ask one predicate, same-block?.

What changed

• engines/racket/compose.rkt: the warichu run contributes the paragraph's own block
  size to the line and nothing more; a member's advance is its body plus the amount after
  it inside its row, and the member that ends a row reports its body alone; neither
  ladder reads a boundary the line was not composed from. warichu-layout no longer
  answers a height nobody asks for.
• engines/racket/tests/test-compose.rkt: three cases computed by hand from §3.4.2 and
  Table 1 — the full-size note's block extent and placements, the in-row amount and the
  advance that reaches it, and the overrun a three-em measure produces rather than a
  squeezed block. All three fail on the previous engine.
• engines/ocaml/probe/census.ml: five further constructs variants and two further
  tabs ones reach both shapes at every one of the 529 class pairs —
  warichu-full-size and its vertical mirror, warichu-pair-inside,
  warichu-pair-inside-row, warichu-pair-inside-justified,
  inside-full-size-warichu and -found. Against the previous engine they report 1,643
  and 1,058 differing responses; against this one, none.
• docs/decisions/stacked-structure-geometry.md publishes both readings and why, and the
  census counts every file quotes follow the new variants.

Measurements

Census	Requests	Rust vs OCaml	Rust vs Racket
spacing	2,116	0	0
break	2,116	0	0
reduction	3,174	0	0
expansion	3,174	0	0
vertical	5,290	0	0
tate-chu-yoko	4,761	0	0
ruby	37,030	0	0
constructs	18,515	0	0
tabs	31,211	0	0
widow	13,225	0	0
total	120,612	0	0

just conform-racket, just conform-ocaml and the Rust sample engine each answer all
eighty-nine built-in cases at exit 0; just check, just design and just ci are green
locally.

One thing this PR deliberately does not ask

A sixth constructs variant — the same pair inside the note on a line that has to give
space back — is absent, and its comment says why. Where a note's two sublines meet at a
Table 1 amount, the Rust and OCaml engines do not agree with each other: the Rust engine
divides the line's arrears over that in-block boundary and lays nothing down there, so it
gives back half of what it needs and reports layout.overfull; the OCaml engine does not
offer the boundary at all. This branch's Racket engine answers as OCaml does, which is
what the reading above says. Fifteen coordinates show it, all of the form
census/constructs/cl-01+cl-02/… — a repro is 漢〈〉あ漢 with the note at the half em, a
warichu over the three, and a three-em measure. Worth its own issue rather than a census
that reports a nonzero count.

While measuring it, one further Racket coordinate turned up that is not fixed here and
is nobody's regression: a furawake row is laid out from bare advances, so a member
before a Table 1 amount inside its row is placed and reported the way #24 described for a
warichu. Fixing it needs the boundary after a furawake block to be read against the
block's last character rather than its first, which is a wider change to how
compose.rkt makes one item of a furawake — also its own issue.

🤖 Generated with Claude Code

https://claude.ai/code/session_01N8KNy2ejPqy81P2hVcRUjs