a0b32b4e - Say why a completed order may fall back to its creation date

[TaprootFreak]

Follow-up to #1207 (merged), closing the last open review point from it.

formatTimestamp reads the valuta timestamp only while the order is completed, and falls back to the creation date inside that branch. The comment explained why the valuta is tied to the completed state, but said nothing about why that fallback exists — and under the rule that a fallback carries its justification in the code, that is the one thing missing.

Getting that justification right took three attempts, and both discarded ones were wrong in a way worth recording:

1. The first claimed a historical data gap — orders completed before the column existed. There is no such gap: the migration that added the column backfilled every existing Completed row from updated, and production holds 189 completed orders, none without a valuta.
2. The second said the fallback guards the invariant. It does not. It hides a violation behind a less precise date.

The comment now says that plainly, and why hiding it is the right trade in a rendered row and not where money depends on it — accrueTranche() in the backend raises the same anomaly rather than working around it.

Comment only, no behaviour change: across all three commits the diff touches nothing but comment lines.

[TaprootFreak]

Three review passes to get one comment right. Both discarded versions stated something untrue:

1. The first justified the fallback with orders completed before the column existed. No such orders exist — the migration backfilled every one of them, and production holds none without a valuta.
2. The second said the fallback guards the invariant. It does not; it hides a violation behind a less precise date.

The wording now names the trade instead of implying protection, and points at the contrast in the backend, where the same anomaly is raised rather than worked around. No behaviour changed at any point — the diff touches comment lines only.