e710bc80 - Route EUR deposits to Bank Frick

[TaprootFreak]

Change

EUR bank transfers are routed to Bank Frick, hardcoded in the deposit selector.

BankService.getBank() previously excluded Bank Frick by name, so Olkypay was the only EUR deposit
target it could return. That exclusion is replaced by the opposite rule:

if (currency === 'EUR' && paymentMethod === FiatPaymentMethod.BANK) {
  const frickEur = receiveBanks
    .filter((bank) => bank.name === IbanBankName.FRICK && bank.currency === 'EUR')
    .sort((a, b) => b.id - a.id)[0];
  if (frickEur) return frickEur;
}

// every path below keeps the categorical exclusion the name filter provided before
const banks = receiveBanks.filter((bank) => bank.name !== IbanBankName.FRICK);

The rule is narrow on purpose

Only EUR bank transfers. The condition is positive (paymentMethod === BANK), so instant and card
requests never enter it. SEPA Instant matters here: Bank Frick does not offer it (sctInst=false), so
an instant request has to reach a bank that can actually execute it.

Every other path keeps the old exclusion. The removed name filter kept Bank Frick out of the whole
selector, not just one branch. Replacing it with an EUR-only rule would have made Frick a candidate
again wherever the rule does not reach — a CHF request could have hit the Frick franc row, and an EUR
instant request with no sctInst bank available would have fallen through to the generic fallback and
landed there too. So the exclusion is restored for everything after the rule; only the explicit rule
may return Frick.

Other banks stay a fallback. The rule applies only when a receiving Frick EUR row exists. If it is
receive=false, the request falls through to the existing selection instead of failing.

Ambiguity is resolved deterministically. (name, currency) is not unique in the schema, so if
several Frick EUR rows were ever active at once, the highest id wins — the same way
getBankInternal already resolves an ambiguous pair. Otherwise the displayed IBAN could change with
the repository's row order.

Scope

The outbound path is untouched: FiatOutputService keeps excluding Bank Frick from automatic sender
selection, so payouts still require explicit assignment. Deposit routing and payout selection are
independent directions.

Two changes unrelated to the routing rule are kept because they are correct either way:
getBank()/getMatchingBank() now declare the Bank | undefined both find() calls can produce,
and buildBankResponse states the non-null precondition it already relied on.

Trade-off

This is a code constant, not configuration: switching the EUR deposit target back, or to another
bank, requires a release. That is the explicit product decision behind this PR — an earlier revision
implemented it as a Bank.receivePriority column so the switch would be a data change, and that
approach was dropped in favour of the hardcoded rule.

Tests

bank.service.spec.ts covers the rule and each of its limits: an EUR transfer reaching Frick even
when the incumbent is listed first; the fallback when the Frick row is receive=false; the EUR row
winning over the Frick CHF row; the highest-id row winning when two Frick EUR rows are active; a CHF
request not being captured by a Frick franc row listed first; an EUR instant request with no
sctInst bank available still not reaching Frick; a card request not reaching it either; and the
unsupported-currency fallback landing on the incumbent in both input orders.

Every case lists the expected winner where input order alone cannot explain a pass. The rule's three
guards were additionally checked by breaking them one at a time: removing the categorical exclusion
fails exactly the four path tests, weakening === BANK fails the card test, and dropping the id sort
fails the tie-break test.

[github-actions]

❌ ESLint: 1 errors, 2 warnings

[TaprootFreak]

Ready after 6 review passes (2 independent reviews per pass: conformance and logic).

Substantive changes made during review, in the order they were found:

1. Ranking alone did not preserve the previous behaviour. The removed filter excluded a bank
   categorically; a low rank merely deprioritises it. Whenever the incumbent for a currency was
   missing or receive=false, or the sctInst lookup fell through to the general fallback, the
   previously excluded bank would have been shown to a customer without anyone switching it on.
   receivePriority is now nullable — NULL means not eligible — and eligibility is filtered
   before ranking.
2. The migration had been edited in place while keeping its class name. TypeORM identifies a
   migration by name, so a database that had already run the earlier version would never have run
   the corrected one. It now carries a fresh timestamp and class name; if the old version did run
   somewhere, ADD COLUMN fails loudly instead of leaving a silently wrong state.
3. The seed data did not carry the new column. A fresh database is migrated while bank is
   still empty, so the backfill touches nothing and the seed then inserts every bank without the
   column — leaving local, CI and onboarding environments without a single eligible deposit bank.
4. Return types. getBank() and getMatchingBank() now declare Bank | undefined, which both
   find() calls can produce, and buildBankResponse states its non-null precondition instead of
   accepting a value it dereferences unconditionally.
5. Scope of the eligibility guarantee. The entity comment, migration docstring, seed comment and
   this description claimed a NULL bank is never offered to a customer at all. It is scoped to the
   generic selector: explicit personal-IBAN paths resolve their own bank and are not gated by this
   column — they never were.

Beyond the test suite, the ordering and eligibility rules were checked by deliberately breaking them
and confirming that exactly the responsible tests fail: removing the id tie-breaker fails only the
two deploy-safety cases, removing the eligibility filter fails only the three NULL cases, and
replacing != null with a truthiness check fails only the receivePriority: 0 case.

[TaprootFreak]

Ready. The approach changed mid-review: an earlier revision made the deposit target a
Bank.receivePriority column so the switch would be a data change. That was dropped in favour of the
hardcoded rule now in the diff, and the column, its migration and the seed entries were removed again.

3 review passes on the final approach (2 independent reviews per pass: conformance and logic).
What they found, in order:

1. The removed name filter was categorical, the new rule was not. Excluding Bank Frick by name
   kept it out of the whole selector. Replacing that with an EUR-only rule silently dropped the
   exclusion everywhere the rule does not reach: a CHF request could return the Frick franc row
   (receive=true in production, in an order the query does not guarantee), an EUR instant request
   with no sctInst bank available fell through to the generic fallback and could land there too, and
   the condition tested !== INSTANT, which is also true for CARD. The rule is now scoped positively
   to BANK, and the categorical exclusion is restored for everything after it.
2. The tie-breaker contradicted attribution. Resolving several qualifying rows by highest id
   conflicted with selectAttributionBank, which prefers the asset-linked row because that binding is
   what isBankMatching and the booked bank_tx history are keyed on — and getReceiveBanks() does
   not even load the asset relation, so the preference could never have applied. The rule now resolves
   through getBankInternal, which is cached and does load it.
3. Test and comment corrections. A missing case (attributed row not receiving while another Frick
   row does — no substitution may happen), and an unsafe type assertion in a new mock.

Three comments in this PR promised more than the code holds and were tightened: the guarantee is the
selection rule, not cache coherence between ibanCache and the repository cache.

Each guard was additionally checked by breaking it: removing the categorical exclusion fails exactly
the four path tests, weakening === BANK fails the card test, dropping the attribution resolution
fails the asset-preference test, and removing the receive check fails the fallback test.

Two pre-existing weaknesses were found but deliberately left alone, as they concern code this diff
does not touch: ibanCache is loaded once at module init while bank rows are otherwise read through a
5-minute cache, so the two can disagree after a runtime edit until restart; and
getBankInternal() declares Promise<Bank> while returning undefined for an empty result, with
three existing callers dereferencing it unguarded.