fix(canvas): Pool, Register and Parameter value rows sit too close to node silhouettes #332

Summary

In a Pool, a Register and a Parameter, the title starts after its kind chip, but the rows under it start at the content edge. A Pool's value sits 14 px before its title text and, on the Pool's slanted side, on or across the outline; a Register's value sits 13 to 28 px before its title text and inside the keyboard-focus ring. This has been so since the first implementation; it is not a regression of #325 or v0.21.0. Planned as v0.21.2: Option C plus minimal widening, with no residual overlap, for these three kinds.

Measured

Read-only, on main 7e66da2 (dev server) and production v0.21.1 · build 7e66da2 (real UI; the two agree within 0.6 px on every node), in Chrome, desktop and phone, light, dark and forced colours. Per row: the glyphs' real extent (a DOM Range), the silhouette's fill edge at that row's height (isPointInFill), the clearance between them, and the start relative to the title text. A synthetic graph with every kind and the values 0, 90, 189, -12.5, 3.14, 1234567.89, a long unit and an invalid Register, plus every node of the Coffee, gacha and early MMO templates (183 nodes).

• The same in every state: selection, keyboard focus, invalid, Focus mode and the activity overlay move no row.
• The canvas is physically left-to-right in every language (docs/localization.md §L9.2), so ar measures the same; a row can still resolve its own text direction to RTL (an Arabic unit with dir="auto").
• L1 hides the detail rows and L0 the whole body.

Measured, deferred

The silhouette is drawn with preserveAspectRatio="none", so its arrow point, notches and slant grow in proportion to the node's width. Applying the contract below to these rows widened 37 template nodes by up to 49 px and made the title clearance worse on 33 of them. They need a silhouette whose point, notch and slant depths stay a fixed number of px, which is separate structural work.

Contract: Option C plus minimal widening

It applies only to these rows: a Pool's current value and capacity, a Register's result and its = expr preview, a Parameter's value and unit.

1. Each row starts where the title text starts: the chip plus its gap, 14 px from the content edge.
2. Each row's glyphs are at least 8 px inside the silhouette at the row's own height (the 6 px focus ring plus 2), which also clears the slanted Pool side.
3. Both are measured from the physical start of the node's stack, not from the row element's own dir="auto" direction.
4. When the node's current width already satisfies 1 and 2, its size does not change.
5. When it does not, only that node widens, by the minimum that satisfies 1 and 2.
6. A very long user string, a long = expr included, still follows the existing 260 px maximum width and ellipsis rules; nothing widens without bound. At the maximum width, no glyph may cross the silhouette. A row that would not fit whole even at 260 px does not widen its node; it ends in its ellipsis at the current width.
7. Title clearance: a title that had 8 px or more keeps at least max(8 px, its clearance − 0.5 px); a title that had less than 8 px loses none of it.
8. Height comes first: a widening that would unwrap a title (and so change the node's height) does not happen; the row ends in its ellipsis instead. Where the title rule or the height rule stops a widening, the row is cut the same way, and the cut is visible (1234567.89 shows as 12345…). Only the display is cut; the stored value, the file and every calculation are unchanged.
9. Unchanged: node positions, heights, saved coordinates, the engine, files and digests. On a node whose width actually changes, its ports and the drawn routing move with the new outline; nothing else moves.
10. Residual overlap: 0. No row of these three kinds crosses its silhouette.
11. Source, Drain, Converter, Gate and End rows are unchanged.

Implementation constraint

• No per-frame measurement. The offsets and any widening are computed only when a node's content, the language or the node's size changes, inside the existing NodeFrame measurement, and cached there. Any change of a row's actual text (digits, unit, sign, decimal point, expression) is read again at the next settle; a playback animation frame never is.

Expected impact

• Measured after implementation: in the three templates, exactly one node widens, the early MMO Register r_income, by 5.66 px (126.84 to 132.5 px). The estimate before implementation was 4 Registers by up to about 14 px; rule 6 keeps the rest at their width. Node heights, positions and every drawn connection in the templates are unchanged.
• Visual baselines that show these node bodies at L2 or L1 change; L0 ones do not. The baselines are updated only after the actual failing list has been reviewed against its before images and approved.

Tests

• A new end-to-end spec that reads the drawn geometry of every Pool, Register and Parameter row: its start is at the title text's start or later; its clearance at its own height is at least 8 px at both ends; zero rows cross a silhouette in the synthetic graph and every template; node heights and positions equal main's, and widths equal main's except the pinned list; the same selected, focused, invalid and in Focus mode; an Arabic case; a measurement counter that does not move per animation frame.
• A unit test for the fill the silhouette leaves at a given height, and for the fit itself.
• The existing value-driven Register test (a Register never clips its own number) and the long-label tests keep passing.

Out of scope

• The Source, Drain and Converter mode lines and the Gate's mode line, two-line Pool titles near the slanted side, and the width-proportional pointed, notched and slanted silhouettes: measured, deferred to a separate follow-up.
• The activity overlay (feat(playback): play execution visualization — taken paths, +N badges, arrival and conversion cues #330).
• No manual screen-reader check; no text or accessibility tree changes.