Key-signature furniture width must scale with the actual number of accidentals in the signature, not a 3-tier bucket

A key signature's rendered width is directly proportional to how many sharp or flat glyphs it contains (1 through 7) — this is purely mechanical (each accidental glyph has a fixed advance width) and any width model that doesn't scale per-accidental will systematically misjudge signatures at the extremes.

`keySigExtra` (lines 788-789) is a crude 3-bucket function: `0` for {C, Am}; `10` for {G, D, F, Em, Dm, Bm}; `20` for everything else. This bucket already mixes accidental counts of 1 and 2 (G=1♯, D=2♯, F=1♭, Em=1♯, Dm=1♭, Bm=2♯ are all lumped at +10), and the `20` bucket is worse: it covers EVERY key from 2 to 7 accidentals uniformly (A=3♯, E=4♯, B=5♯, F#=6♯, C#=7♯, Bb=2♭, Eb=3♭, Ab=4♭, Db=5♭, Gb=6♭, Cb=7♭ all get the identical +20) — a 7-accidental key needs roughly 3.5x the furniture width of a 2-accidental key in that same bucket, and Gradus gives both the identical allowance.

SMuFL glyph metadata (accidental advance widths, summed per key signature); Read, Music Notation (key-signature layout enumerated by accidental count); uncontroversial across all engraving sources.

This rule can be decided from pitches, durations and voices — no layout required. A validator can check it before anything is drawn.