fix(gs): allow querying the custody order completion timestamp

[TaprootFreak]

What

Adds custody_order.completedAt to DebugAllowedColumns.

Why

The column was introduced together with the sZCHF saving position (#4418) as the immutable value date the accrued-interest calculation runs on, but it was never added to the debug allowlist. A structured query against it fails with Column 'completedAt' is not allowed on this table, which means neither the value date of an individual order nor the result of the migration's backfill can be inspected in operation.

The column is a plain timestamp with no personal data — the same class as created and updated, which are allowed on every table.

Scope

Verified against the merge commit of #4418 that completedAt is the only column that PR introduced: it is the sole new @Column in the only entity file the commit touches. The sZCHF asset itself came in through a data migration into the existing table, not a schema change.

Two further columns on this table are absent from the allowlist (transactionRequestId, transactionId, both physical FK columns from pre-existing relations). They predate #4418 and are deliberately left untouched here — widening the allowlist beyond this regression is a separate decision.

[TaprootFreak]

Zero findings after one review pass (conformance and logic in one, given the size of the change).

Confirmed along the way: completedAt is the only column #4418 introduced — it is the sole new @Column in the only entity file that merge commit touches, and the asset itself arrived through a data migration into the existing table. The allowlist was never touched by that PR, so this is a genuine omission rather than a deliberate exclusion. custody_account_access.deactivatedAt is the precedent for a bespoke timestamp beyond created/updated being allowed.

The two FK columns left out of scope (transactionRequestId, transactionId) were traced to a commit from February 2025, well before #4418 — no hidden regression there.