Progression.ToString() puts bar lines in the wrong place: after a sub-beat chord | lands mid-bar, and a chord held across a barline gets none #475

What's wrong

According to the spec, Progression.ToString() writes | at bar boundaries. 2026-07-02-music-type-safe-factories-design.md L121:``

Bar lines | are cosmetic: ToString inserts them at bar boundaries; Parse derives duration from the slashes and treats | as validation.

The implementation (Progression.Parse.cs L14-L56) gets this wrong in two ways:

1. After a sub-beat chord. Any Chord@n/d (sub-beat) event sets beatCursor = 0, marked "cosmetic only". The next chord therefore always gets a | in front of it, wherever it really falls in the bar.
2. Across a barline. A | is written only when a chord starts exactly on a boundary. A chord held across a barline gets none, even though Parse already accepts G | /.

Reproduction (4/4)

Round-trip equality still holds, because Parse skips every | token (L112). But the text is what Section.ToString() and Arrangement.ToString() show people, and it misstates the bar structure.

Parse also accepts "4/4 C | G / / / / / | | F", so the "| as validation" half of the spec was never implemented either.

Acceptance criteria

• ToString tracks the position in the bar as an exact fraction (a Duration), not a whole-beat counter.
• It writes | at each multiple of TimeSignature.BarDuration, including inside a held chord (G | /).
• Both examples above produce the "Correct chart" column.
• Existing round-trip tests stay green.
• Decide separately whether Parse should reject a | that is not on a bar boundary, as the spec says, or whether the spec should be amended to say | is ignored.

Related, not a duplicate: #328 (Parse drops slashes after a Chord@n/d cell).