investigate api dropping elements marked support=full on round-trip

[webern]

Surfaced by the round-trip failure classifier (#211, PR #217).

What

The classifier diffs each failing file as an element multiset and cross-references data/api.features.xml. The most-dropped elements are almost all marked support="full" in our own audit, yet they vanish on round-trip:

element	files affected	audited support
part-group	373	full
staff	297	full
lyric / text / syllabic	~115	full
page-margins + *-margin	~99	full
voice	96	full
measure-numbering	88	full
direction / direction-type	71	full
staff-layout	33	partial

Spot-checked synthetic/accent.3.0.xml: expected has <part-group> twice, actual has it zero times.

The question

Each of these is one of two things, and they need to be told apart per element:

1. a genuine impl round-trip bug (an element we claim to model is being dropped), or
2. api.features.xml overstating support (the element is really partial/none and the audit is wrong).

Either way it's actionable: (1) is a bug fix, (2) is an audit correction.

Caveat

The comparison is strict full-DOM and this branch's baseline is ungrown (#208/#209), so these counts are the raw landscape, not a regression. #208 notes the api drops some subtrees by design — the point of this issue is the elements above are marked full, so by-design dropping would itself be the bug (a mislabel).

Suggested approach

Triage the top offenders one at a time (start with part-group, staff, lyric, voice). The add-mx-api-feature skill covers the impl wiring; the api-feature-audit skill covers correcting support levels.

Repro

make dump-api-roundtrip && make classify-api-roundtrip
# build/api/classified.json: missing_elements per file, cross-referenced to support

References

• Part of api: expand corpus coverage of the api round-trip pass-list #208
• Found by api: classify corpus round-trip failures by root cause (drop-only, reorder, enum bug, missing feature) #211 / PR feat: dump and classify api round-trip failures #217