feat: model unmeasured tremolos and the full slash range in mx::api

[rpatters1]

Human Summary

Unmeasured tremolos (the buzz roll) now round-trip through mx::api, keeping their SMuFL glyph name. One-note tremolos cover MusicXML's full 1-8 slash range instead of silently collapsing 6, 7, and 8 down to three.

Summary

MusicXML's <tremolo> has three kinds and mx::api modeled two of them. An unmeasured tremolo (<tremolo type="unmeasured">0</tremolo>) was labeled "this tremolo is not a mark" by OrnamentsFunctions and then discarded by parseOrnamentsSet, so it vanished on read and could not be written at all. mx::core models it completely; the gap was confined to the api and impl layers.

MarkType::tremoloUnmeasured joins the existing tremolo enumerators. Which kind of tremolo a mark is stays in MarkType, where it already lived for tremoloSingleOne through tremoloSingleFive and tremoloStart/tremoloStop, rather than becoming a second type field in the payload that could contradict it.

TremoloMarkData gains an optional smufl glyph name, following the precedent in PercussionData and NoteData::noteheadSmufl. It is read and written for every tremolo type, not only unmeasured. MusicXML defines no meaning for it elsewhere, but recording it verbatim costs nothing and stops synthetic/tremolo.3.1.xml from losing the attribute it exists to cover.

One-note tremolos now cover the whole tremolo-marks range. The reader handled 0 through 5 and let 6, 7, and 8 fall through to the ornamentsMap default, silently rewriting a seven-slash tremolo as three. tremoloSingleSix, tremoloSingleSeven, and tremoloSingleEight close that, and both slash-count lookups become switches. Note that SMuFL only provides precomposed glyphs for the first five; because those are combining marks, a renderer builds the higher counts by stacking them.

A count of 0 on a single-type tremolo still reads back as three slashes. It is legal MusicXML -- the 3.0 schema allowed it years before unmeasured existed -- but degenerate, since zero slashes draw nothing. The fallback is now documented, with a TODO to log the downgrade if mx ever grows a warning channel.

Adds data/synthetic/tremolo.unmeasured.3.1.xml and pins it in the api round-trip baseline. It omits the font and color attributes its tremolo.3.0 and tremolo.3.1 siblings carry, because MarkData models neither; those two files still fail the round trip on that unrelated limitation. The corert pinned count moves to 837.

Testing

• make api-test MX_RUNNING_IN_DOCKER=1 (498 test cases, 5487 assertions)
• make api-roundtrip MX_RUNNING_IN_DOCKER=1 (297 pinned files, 0 failed)
• make core-roundtrip-test MX_RUNNING_IN_DOCKER=1 (838 test cases, 837 pinned files)
• make audit MX_RUNNING_IN_DOCKER=1 (regenerates data/corpus.xml and the new .features.xml sidecar)
• Three new/extended cases in NoteDataTest: an api round trip of tremoloUnmeasured carrying a glyph name, a read of data/synthetic/tremolo.unmeasured.3.1.xml pinning the core to api path, and the existing tremolos case extended from five slashes to eight
• data/synthetic/tremolo.unmeasured.3.1.xml validated with xmllint --nonet --schema docs/musicxml-3.1-8bbe8e5.xsd
• Strict unity build of target mx
• git diff --check
• make fmt-check MX_RUNNING_IN_DOCKER=1 clean for every file this PR touches. A local run also flags src/include/mx/api/ApiEquality.h, which this branch does not modify -- local clang-format is 19.1.6 while CI pins 18.

[rpatters1]

The linux build error is an insidious merge issue. Two parallel PRs bumped the number of input files by one file. That means that the count tracker only got bumped once but the number of files got bumped twice. There's a counter that needs to be manually increased by 1.

[webern]

The linux build error is an insidious merge issue. Two parallel PRs bumped the number of input files by one file. That means that the count tracker only got bumped once but the number of files got bumped twice. There's a counter that needs to be manually increased by 1.

Yeah that check is kind of annoying. Easy fix, I can take care of it.