feat: configurable per-slot font weight for bundled Cascadia Code

[nikicat]

Summary

Adds an optional weight = <number> field to each per-slot font section
(fonts.regular, fonts.bold, fonts.italic, fonts.bold-italic). When the
slot is served by the bundled Cascadia Code variable font, the value is baked
into the wght axis at shape and rasterize time — so a user who wants a lighter
regular face can write weight = 350 instead of installing a system "Cascadia
Code Light". Refs #1577.

Details

• from_static_slice_with_wght takes the wght axis value and the logical
  CSS-style weight as separate parameters, decoupling the rendered axis from the
  cascade-match weight — so is_bold() and bold-fallback routing still see
  Weight::BOLD for bold slots even when the user picks a lighter axis (e.g. 500).
• The terminal grid path (grid_emit::shape_run_swash / rasterize_glyph_native)
  now applies the wght variation via a per-rasterizer cache mirroring
  sugarloaf::text; macOS gets it through the CTFont handle.
• Config live-reload propagates a weight change: the grid rasterizer and per-panel
  glyph atlases are rebuilt and a redraw is scheduled (the UpdateConfig handler
  previously mutated state without requesting a frame).
• The 700 bold threshold is centralized on swash::Weight::BOLD.
• man page: per-slot signatures updated to reflect that weight deserializes, bold
  defaults corrected to WGHT_BOLD (700), and the phantom width column dropped.

Testing

cargo test -p sugarloaf — TOML deserialization, full FontLibrary::load
per-slot wght_variation, and axis/logical-weight decoupling.

Refs #1577

🤖 Generated with Claude Code

[nikicat]

Pushed a follow-up commit fixing a regression in this same feature, found after opening the PR:

fix(font): resolve wght axis at rasterize time, not via shape side-cache

Bold / bold-italic glyphs could render at the variable font's default 400 weight instead of 700, with which glyphs were affected varying per window. rasterize_glyph_native read the wght axis from wght_variation_cache, a per-font_id side cache that only shape_run_swash populates — but shaping is skipped on a shaped-run cache hit, so a glyph could reach rasterization with no cache entry, get flatten()ed to None, and rasterize at the default instance (then cached permanently, since the atlas key carries no weight). The fix resolves wght from the FontLibrary on a cache miss (same lookup shaping uses), making the rasterized weight a function of font identity rather than frame/shape ordering. Adds bold_slot_rasterizes_bold_without_prior_shaping (fails on the old code: ink 35790 vs 46114).

[nikicat]

Pushed a follow-up fix (f87cd223bb): clear swash's shared coordinate buffer before applying wght.

The earlier resolve wght at rasterize time commit made weight resolution deterministic per font_id, but a residual rare "false bold" remained. Root cause is in swash's ScaleContext/ShapeContext: they keep a single coordinate buffer that every builder(..).variations(..) reuses, and variations() only resize()s + overwrites the axes it's given — it never clears stale entries (unlike normalized_coords()). So an unweighted slot (wght: None) passed an empty variation set, the resize was a no-op, and the glyph inherited the previous build's wght. Since the grid renderer shares one scale_ctx across every font_id, an unweighted italic glyph rasterized right after a bold one rendered bold.

It's rare because it needs a weighted build to immediately precede an unweighted one — and much more frequent under dim text (~30–50%), which fragments runs and interleaves more weights through the shared context.

Fix: normalized_coords(empty) (which clears) before variations() at both the rasterize and shape sites. Added a regression test that drives a bold then an unweighted glyph through one rasterizer and pins that the unweighted glyph matches its no-prior-bold baseline (ink 35790, not bold's 46114) — fails before, passes after.