fix(custody): give the Safe balances a stable order

[TaprootFreak]

Found while reviewing baseline screenshots in DFXswiss/services#1197: two runs against an unchanged dataset produced the same holdings in a different order.

The cause

getUserCustodyBalance loads the balances with findBy(...) and no ordering, and the mapper preserves whatever came back. Without an ORDER BY, Postgres is free to return rows in any order it likes — and does, once a table has seen updates.

What that looks like

A customer opening the Safe twice can see their positions swap places for no reason they can perceive. Nothing is wrong with the figures; the list simply reshuffles. It also makes any screenshot of the Safe unreproducible, which is how this surfaced.

The order

Largest position first, by CHF value, with the asset name breaking ties so the result is fully determined. That is stable, and it is the order someone reading a portfolio expects — the biggest holding at the top.

Sorting happens in the mapper rather than the query because the fiat value only exists after conversion.

A damaged value

NaN makes every difference falsy, so a broken figure fell through to the name comparison — against every other entry, whatever its worth. The ordering lost its transitivity and the position depended on the input order again: the very unpredictability this sort removes, only triggered by a bad figure instead of a missing ORDER BY.

Non-finite values are therefore ranked last rather than compared. They are not thrown, for the reason already recorded a few lines up in the caller: one damaged position must not take the customer's whole balance response down with it.

Tests

Five cases in the existing mapper suite, each feeding the input in an order that would let a naive pass-through slip by:

• descending value, given ascending input
• equal values fall back to the name, given reverse-alphabetical input
• the same input in two different orders yields the same output — the guarantee this exists for
• a negative value sorts behind every positive one; there is a negative balance row in production, so that is not hypothetical
• a non-finite value lands last no matter which order it arrived in, and so does a real infinity

The ordering case earns its name: with three values it held for the broken comparator too, so it would have watched the defect return in silence. Four values with a negative among them separate the two, verified by putting the old line back and watching both tests go red.

npx jest src/subdomains/core/custody --silent
  Test Suites: 6 passed, 6 total
  Tests:       6 skipped, 79 passed, 85 total

npm run type-check      → clean
npx prettier --check    → clean

[TaprootFreak]

Four review passes to zero findings.

The fix itself is small, but it grew a second half along the way. Ordering by value alone still left one case undecided: NaN makes every difference falsy, so a damaged figure fell through to the name comparison — against every other entry, whatever its worth. The ordering lost its transitivity and depended on input order again, which is exactly what this change exists to remove. Non-finite values are ranked last now, not thrown, for the reason already recorded a few lines up in the caller: one damaged position must not take the customer's whole balance response down with it.

The most useful finding was about a test rather than the code. The case named "returns the same order regardless of input order" held for the broken comparator too, given three values — it would have watched the defect return without a word, and only the position checks were doing any work. Four values with a negative among them separate the two. Verified the way such a claim has to be: by putting the old line back and watching both tests go red, then putting it back.