fix: consume implicit one-or-more placeholder in add

[rpatters1]

Human Summary

While trying to build a fretboard diagram, discovered a bug in OneOrMore that could lead to an extra item being generated. This PR fixes that bug.

Summary

OneOrMore now tracks its implicit default placeholder. The first item added to a default-constructed or empty-repaired collection replaces that placeholder; explicitly supplied first items are preserved. Added core regression tests and removed the exporter-specific workaround.

Testing

• Core unit tests: 221 assertions in 44 test cases
• DirectionWriter tests: 30 assertions in 4 test cases
• Changed files pass direct clang-format validation

References

• No issue reference: GitHub issues are disabled for this repository.

[webern]

Interesting idea. It's not a big per-se, just a weird interface arising from the design goal of having invalid files be unrepresentable. This seems like a reasonable interface as well, I.e. the object takes care of it instead of the caller.

It feels like there might be other cases of this? Not to sure.

[rpatters1]

I believe codex only found the one. (The output was a little confusing.) All the others seemed to be explicitly setting their first element, which this change accommodates.

[rpatters1]

The "exporter-specific workaround" mentioned in the description was my initial fix for FrameData, never committed. I realized we probably needed a fix in OneOrMore.

[webern]

Interesting idea. It's not a big per-se, just a weird interface arising from the design goal of having invalid files be unrepresentable. This seems like a reasonable interface as well, I.e. the object takes care of it instead of the caller.

It feels like there might be other cases of this? Not to sure.

Had opus open #396