Say why a back-dated ongoing entry cannot be saved

[SiteRelEnby]

The follow-up left open by #97. That PR fixed adding a closed history entry; this one handles the "still ongoing" case it deliberately left alone.

The case

An entry left open is a switch, not history, so the server ends every open front at its start. Back-date that start to before somebody currently fronting began, and their end lands before their own beginning: ck_fronts_ended_after_started refuses it and the request answers 500.

The user sees "Internal server error". 5xx deliberately keeps the generic wording - server internals are not the user's problem and may say more than they should - so there is no explaining this after the fact. It has to be caught before the request goes out.

The check

The sheet now names who it clashes with and when they started, and offers the two ways out: a later start, or an end time, which records it as history and leaves the live roster alone.

It is narrow on purpose. Three cases skip it entirely, because none of them replace anything:

• Editing an existing entry. A PATCH never ends other fronts.
• A closed entry. Since Record a past front entry without disturbing the live one #97 that is recorded without touching the live roster.
• The system's replace default off. Nothing gets ended, so nothing can be ended illegally.

Two edge cases decided deliberately:

• Equal timestamps pass. A front ending at the instant it began is a zero-length entry rather than a backwards one, and the constraint allows it.
• An unparseable started_at is not treated as a clash. The server is the authority on its own rows, and refusing a legitimate entry over a formatting disagreement this client cannot read is the worse error.

Where the data comes from

GET /v1/fronts/current when the sheet opens, not the loaded history page.

That was the open question in the backlog note: the history list is paginated, so an open front is only probably on it, and a validation that is only probably right is worse than none - it would wave through exactly the entry that 500s. Asked fresh on each open, since who is fronting changes between openings.

Tests

Six, against openFrontsStartingAfter, which the rule was extracted into so it could be tested without a Compose harness: the breaking case, the safe case, equal timestamps, every clashing front reported rather than just the first, nothing open, and the unreadable timestamp.

All clashing fronts are named rather than only the first, because fixing one and resubmitting into the next is a poor way to discover there were two.