fix(text): resolve a declared font weight in one place, so paint and measure agree

[LeadcodeDev]

A numeric font-weight of 600 or more was painted as 700. The painter collapsed it to FontWeight::Bold, the measurer passed the exact number through, and when several weights of a family are registered the two resolve different files: 900 was drawn in 800 or 700, and the box measured on the 900 face came out a few pixels narrower than the face actually painted. A title that fits on one line then wrapped at paint time while its box kept a single-line height, so the second line was drawn over the next sibling.

Measuring the other direction turned up two divergences the issue does not mention, both the same kind of thing. bolder measured 800 and painted 700. lighter measured 300 and painted 400. gradient_text already passed numbers through, so it was correct on the numeric case and wrong on both keywords — which is why fixing only the >= 600 arm would have left two thirds of the defect in place.

The reason all three existed is that the mapping was written seven times: once in intrinsic.rs::weight_to_u16 for measurement, and six times as a match in text, caption, counter, number_wheel, rich_text and gradient_text. renderer::css_font_weight is now the single expression of it and all seven callers go through it. That is the part worth reviewing rather than the arithmetic: the agreement between measuring and painting stops being a rule each painter has to remember and becomes a thing there is only one place to write.

Five painters dropped the schema FontWeight they were using as an intermediary. It stays where it is genuinely the input rather than a re-encoding of a CssStyle: shape's embedded text config, and rich_text's per-span override, both deserialised from JSON. rich_text::make_font now takes a resolved Weight, so the span path converts its own schema value through the exact to_skia_weight and the default path goes through css_font_weight. shape::text_in_shape_font_style is untouched; its mapping was already exact.

Verification. Reproduced on main offline, since Inter 400-900 are already in the font cache and a cached face fetches nothing. Varying only fonts[0].weights on the issue's scenario, the title's ink rows and black ink mass:

loaded weights	before	after
[900]	436-548, 1 line, 80885	436-548, 1 line, 80885
[800, 900]	436-698, 2 lines, 67713	436-548, 1 line, 80885
[500, 900]	436-698, 2 lines, 46412	436-548, 1 line, 80885
[400 … 900]	436-698, 2 lines, 60161	436-548, 1 line, 80885

All four now match the single-weight render exactly. The identical ink mass is the point: it shows the painted face is the 900 one, not merely that the wrap stopped. [500, 900] carrying the least ink before is the tie at distance 200 resolving to the first registered variant, as the issue said.

Four tests. A table over every input class of css_font_weight, including the 1..1000 clamp. One that registers two faces at 800 and 900 with distinguishable bytes and asserts font-weight: 900 reaches the 900 one, while asking for 700 — what the painter used to do — lands on the 800 face; that one needs no font files and no network, so it holds on a bare runner. Two on Caption::resolve_font_style, which is a real paint path: one over 600/700/800/900, one on bolder and lighter. The two existing tests there covered only bold and 350, which is why the bug survived them.

cargo fmt --all --check, cargo clippy --workspace --all-targets --features rustmotion/studio -- -D warnings, cargo test --workspace --features rustmotion/studio: 2150 passed, 0 failed, 10 ignored across 52 suites.

The toolchain pin this needed is merged (#467), so this targets main and its diff is this change alone.

Closes #466