fix(number_wheel): resolve text-align instead of always painting from the left

[LeadcodeDev]

Closes #410.

Symptom

A number_wheel in a full-width box with text-align: center lands hard against
the left edge, while the text label under it centres correctly.

Cause

paint_content started its draw loop at a literal origin and never read
style.text_align or the layout width:

let mut x = 0.0f32;   // the whole strip is laid out from here

This is the same defect #337 fixed in gradient_text's draw loop. text,
rich_text, counter and gradient_text all resolve alignment against their
box; number_wheel was the one that was missed.

It stayed invisible because NumberWheelIntrinsic shrinks the box to the digits,
so it only shows once the box is wider than the strip — which is exactly when
someone asks for centring.

Fix

Measure the strip's total advance (fixed-glyph widths plus digit_w per reel),
resolve the alignment offset against layout.width, and start the loop there.
A non-finite or non-positive width falls back to the left edge rather than
painting off-screen; that is the case both the intrinsic measure and a degenerate
flex slot produce.

Tests

Test
text_align_center_centres_the_reels_in_the_box	ink centre within 6 px of the box centre, left margin > 100 px
text_align_right_ends_the_reels_on_the_box_edge	last ink within 8 px of the box edge
no_text_align_still_starts_at_the_box_left_edge	the default is unchanged
a_box_with_no_usable_width_falls_back_to_the_left_edge	0, negative, inf, NaN

Reverting the offset to 0.0 fails the first two with the reported symptom:

a centred number_wheel must sit on the box centre 500, painted [3, 130] with centre 66.5
a right-aligned number_wheel must end on the box edge 1000, last ink at 130

Gate

cargo fmt --all --check clean · cargo clippy --workspace --all-targets --features rustmotion/studio -D warnings clean · cargo test --workspace 1771 passed.