Two date grammars parse the same wire formats and have already drifted

[datlechin]

Found while fixing the result-chart review findings in #2222.

TablePro has two independent grammars for the same thing: recovering a Date from the text a driver puts on the wire.

• TablePro/Core/Services/Formatting/DatabaseDateParser.swift holds an ordered list of nine DateFormatter patterns. DateFormattingService uses it to render a cell, and ResultChartProjector uses it to place a point on a time axis.
• TablePro/Core/Services/Formatting/DateEditingService.swift recognises the same spellings with a regex, for the cell editor.

Nothing forces the two to agree, and they had already drifted. Before #2222 the cell editor accepted 2024-03-01 12:00:00+07 while the display formatter did not, so the same value was editable as a date but rendered as raw text. #2222 closed that particular gap by widening the parser, but only because the chart happened to need it. The next spelling a driver emits will drift again in whichever direction it is added.

They also disagree on a real semantic: DateEditingService reads a value with no offset as GMT, while DatabaseDateParser reads it in the reader's own time zone. For a naive DATETIME those give different instants.

What to do: give one type the grammar and have the other read it. Two things have to survive the merge:

• the naive-value time zone has to be settled deliberately, not inherited from whichever type wins
• DateEditingService captures fractional seconds as text rather than folding them into the Date, which the editor relies on to round-trip a value back to SQL without losing precision

Verified: both files exist on main at edae33c and cover overlapping spellings. DatabaseDateParserTests covers the parser's nine patterns; there is no test asserting the two agree.