feat: expose first-fret text and location in mx::api

[rpatters1]

Human Summary

Round-trip the <first-fret> text and location attributes through mx::api.

Summary

MusicXML's <first-fret> carries two display attributes beside its value: text, the label to
print (Finale writes 4fr. for a frame starting at the fourth fret), and location, whether that
label appears to the left or the right of the grid. mx::core has modeled both since it was
generated, but mx::api exposed only firstFret and isFirstFretSpecified, so the writer emitted
a bare <first-fret>4</first-fret> and a reading application had to invent the label and its side.

FrameData gains firstFretText, an optional string, and firstFretLocation, a new
FirstFretLocation enum whose unspecified default writes no attribute. The two are independent:
MusicXML permits either alone, and a frame that wants only the fret number keeps working untouched.

The value and its is...Specified flag are left as they are rather than folded into a sub-struct,
per the AGENTS.md rule that the legacy sentinel fields are migrated deliberately and separately.

Non-breaking: two new fields on FrameData, both absent by default.

Testing

• New harmonyFrameFirstFretRoundTrip covers both attributes through XML and back;
  harmonyFrameFirstFretBareRoundTrip verifies a frame with neither still emits
  <first-fret>3</first-fret> and reads back as unspecified
• make api-test (6367 assertions in 582 test cases)
• make api-roundtrip (405 of 405 pinned)
• synthetic/first-fret.3.0.xml unlocked and added to the round-trip baseline; confirmed it
  fails on the parent commit with attribute count mismatch at .../frame/first-fret and passes with
  this change

References

• Related to expose the id attribute of harmony and frame in mx::api #406, the other outstanding <frame> gap in the same reader and writer

[webern]

Looks good.