Keep display value anchored to the bottom on font shrink

[sheep-farm]

Summary

When a long number forced the display font to shrink, the Text item's implicit height shrank with it and the number crept upward. This change:

• Gives the display value its own area below the expression (anchors.top: expressionText.bottom; anchors.bottom: parent.bottom).
• Aligns the display text to the bottom of that area (verticalAlignment: Text.AlignBottom).
• Raises the minimum pixel size from 22 to 32 so long results remain readable.

Test plan

• ./bin/test passes (20/20).
• ./bin/build compiles successfully.
• Manual check: long numbers keep the display text aligned to the bottom of the display area.

[omarchybot]

The bottom-anchoring half of this is right, and it fixes a bigger problem than the description claims. Measured on Qt 6.11.1 with the bundled iA Writer Mono S at the 400x568 design size, rendering offscreen: before this change the display's ink bottom sat at y=121 for 0 (76px), but climbed to y=81 for a 15-digit result and y=69 for a 22-character one -- a ~52px jump inside a 122px display area. With verticalAlignment: Text.AlignBottom it stays between y=121 and y=134. Full-size results land in exactly the same place as before, so nothing regresses at 76px.

One correction for the record, since the commit message will outlive the review: the item's implicitHeight does not shrink. QQuickText keeps it at the line height of the declared maximum font.pixelSize -- 99px here -- whatever size HorizontalFit settles on; I measured implicitHeight = 99 for every string tested. What moved the number was the default verticalAlignment: Text.AlignTop, which put the shrunken line at the top of a box still sized for 76px. AlignBottom is the right fix either way; only the explanation is off.

The minimumPixelSize bump from 22 to 32 is the problem. The display line is 344px wide at the design size and this font advances exactly 0.6em, so 32px glyphs are 19.2px and only 17 characters fit. The ratio is scale-invariant, because the face margins are scaledSized too: it is 17 characters at 300px wide and 17 at 1920px wide, against 26 before. backend.display can return up to 22 characters, since formatNumber is QString::number(value, 'g', 15).

The display Text has no elide and no clip, so nothing is elided -- with horizontalAlignment: Text.AlignRight the overflow is drawn at negative x and runs off the left edge of the window. Rendered at 400x568, where the display area spans x=28..372:

• 3.33333333333333e-07, which 1 / 3 = / 1000000 = produces: ink spans x=[29..369] at min 22, and x=[0..369] at min 32 -- the leading 3 is sliced in half at the window edge.
• -1.23456789012345e-308: x=[29..370] at min 22, and x=[9..369] at min 32 -- -1. is entirely off-window, so the number reads 23456789012345e-308.

A negative result silently losing its minus sign is worse than the small font the bump was meant to avoid. Restoring minimumPixelSize: win.scaledSize(22) keeps the anchoring fix and costs nothing. If 32 is worth keeping it needs an elide policy or a shorter display format alongside it, and choosing between "small but complete" and "large but truncated" is a product call rather than a defect fix, so I have not pushed either.

Two things worth knowing about the stack. Commit 9a4b1e0 is already in #7, so whatever lands here lands there. And #3's fixedDecimalPlaces formats with QString::number(value, 'f', places) for places up to 15, which would make 18-plus character displays routine rather than exotic.

./bin/build and ./bin/test both pass on a clean Arch VM with Qt 6.11.1 (19/19). Neither exercises QML, so they say nothing about any of the above.