feat: model direction offset as an anchor plus a fidelity knob

[webern]

Human Summary

This one is sort of complicated. But if I understand it correctly, the <offset> element places a direction somewhere other than where it happens to actually be in the stateful parse position. I believe it is unnecessary, perhaps, in MusicXML. Or perhaps it allows you to place a direction in the measure close to a note that the application attaches the direction to, then say where it actually appears by nudging its time position. It is weird. But this optional offset allows us to represent certain corpus files correctly and, as such, probably is actually needed for correctness in some cases.

Summary

Reworks how a direction's <offset> is modeled so that the anchor a direction belongs to and the drawn-position nudge are two separate, first-class quantities. The goal is that an author positions a direction by the note it belongs to and never has to reach for the arcane <offset> element.

Before. The reader folded <offset> into tickTimePosition and discarded the raw value. tickTimePosition therefore meant the drawn location, and on write the offset was re-synthesized as tickTimePosition - cursor. An offset that landed exactly on a note tick collapsed to zero, so the <offset> silently vanished and the direction re-anchored to the wrong note. The model also could not tell a visual-only offset apart from one meant to move playback.

After.

• tickTimePosition is the anchor -- the musical location (note/beat) the direction belongs to.
• DirectionData::offset (new, std::optional<int>) is the source's <offset>, a drawn-position shift in divisions, kept verbatim or left absent. The drawn position is tickTimePosition + offset.
• The reader stores the anchor and the offset without folding. The writer is field-first: a modeled offset is re-emitted with no sound attribute (an <offset> moves only where the direction is drawn, so playback stays at the anchor); a direction that merely sits off the cursor tick with no modeled offset still gets a synthesized sound="yes" offset, exactly as before.
• MeasureWriter is untouched -- it already places directions by tickTimePosition, which is now the anchor.

Authoring stays simple: set tickTimePosition to where the direction belongs and leave offset absent; the automatic path handles placement. offset is a round-trip fidelity knob you only touch to preserve a source's explicit <offset>.

Breaking change

tickTimePosition changes meaning for offset-bearing directions: it is now the anchor, not the drawn location. Directions without an offset are unaffected (anchor == drawn location). A consumer that reads tickTimePosition for an offset direction and wants the drawn location must now add offset.

The OutOfOrderDoesntThrow / OutOfOrderTorture round-trip tests now assert the effective (drawn) location tickTimePosition + offset, which equals what they previously asserted against the folded tick.

Testing

• Full unit suite passes (5130 assertions in 451 test cases), including the reworked OutOfOrder* direction round-trip tests
• api round-trip discovery: 287 PASS, 0 regressions; the <offset>-bearing corpus files (ly31a_Directions, ly33d_Spanners_OctaveShifts) round-trip their bare <offset> elements byte-for-byte. The pins land in the stacked round-trip PR (test: canonicalize non-semantic direction spellings and pin ly31a #366).

References

• Progresses api: many direction-type subtypes are unmodeled stubs (percussion, metronome extras, harp-pedals, scordatura, ...) #324
• Second of a three-PR stack: octave-shift size (feat: round-trip octave-shift size #365) → direction offset (this) → round-trip canonicalizers + pins (test: canonicalize non-semantic direction spellings and pin ly31a #366)