Fix #223 — accept a K: that names a clef but no key, and draw clef changes

[sbeitzel]

Fix #223

Problem

K:bass, K:clef=bass and [K:clef=bass] were rejected ("Key must start with A–G…") and the clef was dropped. Even K:C clef=bass part way through a tune never reached the page, because the renderer drew one clef per voice for the whole tune.

Parsing and semantics

• KeyFieldParser: a payload with no tonic is read as options only (§3.1.14, §4.6). An empty K: is accepted too. A payload that is neither a key nor options still warns, and now changes nothing.
• KeySignature.statesKey / statesClef record what the field stated. The semantic pass resolves both, so the domain model only carries decided keys:
  • in the header, an empty key is K:none;
  • part way through a voice, the key in force carries on, and a K: with no clef keeps the clef in force (K:G after K:bass stays bass, as in abcm2ps).
• New Event.clefChange(ClefSpec), at the point the field was written. Measure.key is set only by a K: that names a key.

Rendering (checked against abcm2ps -g 8.14)

• A change written against a bar line is drawn as a small clef before that bar. At a line break this is the courtesy clef at the end of the line, and the next system opens with the new clef full size and the key signature already in force.
• A change in the middle of a bar is drawn as a small clef between the notes. The notes before it stay on the old clef.
• A clef change alone draws no key signature. A later key change is drawn for the new clef.
• Noteheads, ledger lines and ledger space follow the clef in force at each event (ResolvedEvent.clef). The emitter's per-system clef is gone.

Tests

• KeyWithoutTonicTests (parser/semantic, 15) and MidTuneClefChangeTests (renderer, 6).
• Full suite passes. No existing snapshot changed.

🤖 Generated with Claude Code