Fix the drawn icons and centre the digit field

[oroderico]

Three things wrong with shapes this firmware draws by hand, found by looking at them scaled up rather than on the device.

The tick was a diagonal bar

It derived both legs from one width: width/3 for the short one. With NAV_ARROW_WIDTH=7 that integer division gives 2, so the short leg was two overlapping squares — barely wider than the low point — and the mark read as a bar, not a check.

Fixed lengths now (3 and 6, roughly the 1:2 a check needs), in a box of its own: the arrow is tall and narrow to read as a triangle, a check this small has to be wider than tall. The box is derived from the legs so it cannot drift from them.

The two arrows were two functions that had drifted

The back arrow and the digit field's scroll hints draw the same shape on different axes — one stepping columns, one stepping rows. Same arithmetic, transposed.

They had drifted in the rounding, which is how this surfaced: the back arrow's half-width is (step + 1) * across / (2 * steps); the digit arrows' left out the + 1, so their first two rows both rounded to zero and the apex came out as a 1px-wide, 2px-tall spike.

One function now, taking a direction. The back arrow's pixels are unchanged — the unified formula reproduces its 1, 3, 5, 7, 7, 9, 11 exactly, checked by rendering the header before and after and comparing the framebuffer byte for byte. The digit arrows drop to six rows, since an 11-wide triangle has exactly six distinct half-widths and a seventh row repeats one.

The digit field sat 13px above centre

Measured, not eyeballed: the stack of arrows and boxes ran y 26..77, centre 51, in a band of 18..110 whose centre is 64.

DIGIT_BOX_Y and the arrow rows were pinned literals, so nothing moved when the arrows changed height and nothing could notice they were off-centre to begin with. They are derived now — from the stack's own parts, and from the band it sits in.

That band differs between the two screens that draw this stack, which is why one pinned y could never suit both: the digit field has only the footer under it, the value box shares its screen with the entropy quality bar. Each centres against what actually bounds it.

The value box moves down 2px as a result. It was not centred above the bar either, just less visibly.

Two things this turned up

The assert meant to keep the down arrow off the footer compared against LIST_FOOTER_Y — the list screens' footer, 11px below the one these actually draw. It would have permitted the overlap it was written to catch. Both placements are asserted now, each against its own bound.

The footer's y was the literal 111 in three renderers; it is SCREEN_FOOTER_Y.

Size

111 insertions, 58 deletions — of which net executable code is +6 lines. The rest is comments, named constants and asserts. +32 bytes of flash (303952, from 303920).

Verification

Host self-test and the 52 Python tests, on every commit individually via git rebase --exec, not just the tip. Each changed shape was rendered off the framebuffer and read at 20x; the digit field's centring was measured from the rendered pixels rather than judged by eye.

Flashed to a TTGO T-Display and walked on the panel: the digit field, the tick in both states, the unchanged back arrow, the orange in each, and the value box's 2px shift all confirmed there.