fix(text): position glyphs at their fractional coordinates

[LeadcodeDev]

Every skia_safe::Font in the engine was built with Skia's defaults, which place glyphs on whole device pixels: subpixel positioning off, baseline snapping on. Everything else on the canvas sits at its exact fractional position, so under any slow motion the box moved by hundredths of a pixel while the glyphs inside it advanced in 1px jumps. What that looks like is a label shivering inside a card that is standing still — a wiggle of a few pixels, a float loop, a camera push-in.

Measured on the scenario from the issue, a text and a 4px bar in one column translated 0 → 3px linearly: the bar's ink centroid tracked the keyframe to the hundredth, the text's held for three frames and then jumped by exactly 1.00px.

renderer::subpixel_font is now the only way to build a Font, and the 107 direct Font::from_typeface calls across 37 files go through it. A single constructor rather than 107 call sites to keep in line: a new component that writes the obvious thing gets the right behaviour, and reintroducing the snapping means deleting the constructor rather than forgetting three setters.

The residue is 0.153px against 0.690px before, not zero, because Skia quantises subpixel positions to quarter-pixels. That is a quarter of the previous error and a fifth of a pixel of the glyph's own antialiasing, rather than a visible step.

centring_keeps_the_gradient_over_the_glyphs had to change what it measures, and it is worth being explicit about why, since a test edited alongside the change it guards deserves the scrutiny. It sampled the rightmost ink column and compared premultiplied channels. With glyph edges no longer snapped, that column is an antialiased fringe rather than a hard edge, so the identical violet read (33, 22, 59) through alpha 61 where the centred case read (139, 92, 246) at full coverage — 33 × 255 / 61 = 138. The gradient was never wrong; the test was reading premultiplied values as if they were colours. It now walks in from the right to a column with real coverage and unpremultiplies before comparing.

Verification — a new integration test renders the issue's scenario frame by frame, separates the text band from the bar band by their ink rows, and asserts the text centroid follows the travel and does not drift against the bar. Red at 0.690px with the constructor's three setters removed, green at 0.153px with them, tolerance 0.25px. Plus cargo fmt --all --check, cargo clippy --workspace --all-targets --features rustmotion/studio -- -D warnings, and cargo test --workspace --features rustmotion/studio: 0 failed. A 40px and a 14px line were also rendered and looked at, since hinting is now off.

Closes #456