(android) Fix wrong fiat unit on payment technical details (then) line

[PeterXMR]

Closes #535.

Summary

In the "Technical details" page of a payment, the (then) fiat value used the user's currently-preferred fiat as the display unit, while the numeric amount was computed from the historical exchange rate (which is recorded in a possibly-different currency). After switching the preferred fiat the line therefore showed a wrong amount with a wrong-but-currently-preferred currency code — e.g. a 1 EUR incoming payment displayed as "1 PHP (then)" after switching the preferred fiat to PHP, instead of "1 EUR (then)".

Change

• phoenix-android/.../PaymentTechnicalView.kt: the (then) line now formats with rateThen.fiatCurrency instead of the user's prefFiat. The (now) line is unchanged (it correctly uses the live rate for the preferred fiat).
• This matches the convention already followed by CsvWriter.convertToFiat in phoenix-shared, which reads exchangeRate.fiatCurrency.name directly off the historical rate.

Tests

Added two JVM unit tests to AmountFormatterTest.kt that lock in the formatter contract the fix relies on:

• then_fiat_uses_historical_rate_currency_not_preferred_fiat
• then_fiat_label_does_not_follow_preferred_fiat_change

Both pass under ./gradlew :phoenix-android:testDebugUnitTest --tests "fr.acinq.phoenix.utils.AmountConverterTest".

Pre-existing build note (not blocking)

phoenix-android/src/test/.../LnurlAuthTest.kt does not compile on current master because Crypto.compact2der was removed in bitcoin-kmp 0.30.0. I temporarily moved the file aside to run the new tests, then restored it untouched — this PR does not touch that file. The unit-test task will need the existing breakage resolved separately before CI can run.

Test plan

• Build passes (:phoenix-android:assembleDebug)
• New unit tests pass
• Manual verification on testnet3

End-to-end verification on testnet3

Reproduced the original bug scenario against a real Phoenix wallet on Android Pixel 4a API 34 emulator, with a real Lightning channel funded via ACINQ's testnet3 LSP.

Setup:

1. Fresh wallet, preferred fiat set to EUR before receiving anything.
2. On-chain deposit from a testnet3 faucet to the swap-in address: tx 5297b4f6…43a29a4a — 189,072 sat, confirmed at block 4,965,924.
3. After 3 confirmations, the ACINQ testnet LSP coordinated a splice-in tx 42061b2351d7…c04149c4b1f, opening channel d48a5c0fd8ae…d1b36654ef9. Net wallet balance: 187,505 sat (deposit − 1,000 sat service fee − 567 sat miner fee).

Step 1 — Technical details before changing preferred fiat (EUR):

Row	Sat	(now)	(then)
Amount received	187,505	≈ 122.41 EUR	≈ 122.41 EUR
Service fees	1,000	≈ 0.66 EUR	≈ 0.66 EUR
Miner fees	567	≈ 0.38 EUR	≈ 0.38 EUR

(now) and (then) match because the live fiat matches the recorded originalFiat.

Step 2 — Switch preferred fiat to PHP, re-open Technical details:

Row	Sat	(now)	(then)
Amount received	187,505	≈ 8,772.42 PHP	≈ 122.41 EUR
Service fees	1,000	≈ 46.79 PHP	≈ 0.66 EUR
Miner fees	567	≈ 26.53 PHP	≈ 0.38 EUR

The (then) line stayed in EUR (the currency recorded at receive time), with the same numeric values as before — exactly the behavior described in #535. The (now) line correctly recomputed against the live PHP rate (8,772.42 PHP / 122.41 EUR ≈ 71.7 PHP/EUR, which matches current real-world rates, confirming the live and historical rate paths are both functioning).

Without this fix the (then) line would have re-labeled to "PHP" while continuing to use the EUR-historical rate as the multiplier, producing the "122.41 PHP" wrong-amount-wrong-unit output reported in the issue.

Screenshots:
Before changing preferred fiat — both (now) and (then) lines show EUR.

After switching preferred fiat to PHP — (now) line correctly shows PHP, (then) line correctly stays in EUR with the same numeric value as before. This is exactly the behavior issue #535 asked for.