a0b32b4e - Expose order timestamps in the Safe activity history

[TaprootFreak]

What

CustodyOrderHistoryDto carried no timestamp at all — only type, status and the amount/asset pairs. A client rendering the account activity had no way to date an entry.

The DTO now carries both timestamps of the order, passed through separately:

• created — when the order was recorded, always present.
• completedAt — the valuta timestamp, present only once the order has completed.

Why not a single field

Collapsing the two (completedAt ?? created) would hand the client a date without telling it what that date means, and would quietly claim a valuta for orders that never completed — including orders stuck in Created, where the gap between the two is precisely the interesting part. The choice of which one to display belongs to the caller.

CustodyOrderHistoryDtoMapper had no test coverage; the added spec pins the pass-through and, in particular, that an unfinished order keeps completedAt undefined rather than inheriting the creation date.

Consumers

Both history endpoints go through the same mapper, so GET /custody/account/:id/order and the user-scoped history gain the fields together. Purely additive — no existing field changes shape.

The UI side is DFXswiss/services#1207, which needs this deployed first; without it the rows simply show no date.

[TaprootFreak]

Two review passes, no changes required to the diff.

Two neighbouring observations came up that are deliberately not addressed here, both in code this PR does not touch:

1. confirmOrder/approveOrder set the status without a precondition on the previous one, so a completed order could in principle be moved back while keeping its completedAt. Checked against production: 189 completed orders, zero rows with Completed and a null valuta, zero rows with a valuta and another status. Pre-existing and not observable today — worth its own ticket.

2. getOrdersByUserData orders by created, while a client displaying the valuta timestamp sorts by a different key. Fixing that properly means moving the query from find() to a QueryBuilder with COALESCE over two camelCase columns — raw SQL whose quoting behaviour mocked unit tests do not catch. That is more risk than a field pass-through should carry, so it stays out. The rows are dated correctly either way; only their order can differ from the dates shown.