Flag failed/refunded/expired swap rows in getTransactions and gate the
carousel pending pill on it, so a dead swap no longer pins the card to
pending forever.

… retired)

Restore flat header structure so the context-menu native view gets its Yoga frame instead of drawing at origin.

Both conflicts resolved by keeping this branch's versions, which deliberately
diverged for New Architecture / Detox reasons that bw/master's changes would
regress:

- components/TransactionsNavigationHeader.tsx: kept our ActionSheet-based
  Manage Funds button. It avoids ToolTipMenu because react-native-context-menu-view
  mispositions under Fabric (overlapping the wallet label); bw/master's
  "FIX: Manage funds layout" keeps ToolTipMenu inside a balanceSection wrapper.
- screen/settings/SelfTest.tsx: kept our removal of the BlueElectrum network
  self-test (network calls + live timers hang Detox/FabricTimersIdlingResource
  on CI); bw/master's "REF: blue electrum" only refactored that block.

getTransactions() merged three feeds (Boltz swaps, boarding UTXOs, SDK
history) and reconciled the swap overlay against the SDK rows with a
fragile fingerprint matcher, so any timestamp skew surfaced one
settlement twice — e.g. a refill also showing as a phantom "Lightning"
row of the same amount.

Rebuild it: getTransactionHistory() is the single source of rows
(boarding entry -> Refill via TxKey.boardingTxid, everything else ->
native Lightning leg). Settled swaps enrich their matching native leg
in place and emit no row of their own; only non-settled swaps that need
visibility (claimable/in-flight/failed/refunded, plus open invoices for
the registry) emit a swap- row. A settlement can no longer appear both
as its native leg and as a swap- row, regardless of timestamp skew.

isInvoiceGeneratedByWallet() now answers from _swapHistory directly so a
settled invoice stays recognizable after its row is enriched onto the leg.

Manage Funds -> Refill had two issues:

1. A refill appeared immediately as a completed "Received / Refill" row and the headline balance jumped right away. fetchBalance() used SDK balance.total (offchain + boarding), so an unconfirmed boarding deposit inflated the balance before it was usable, and the pending boarding row (boarding-utxo-...) rendered as a confirmed receive.

2. After the deposit confirmed, the balance briefly showed ~2x the refill. getBalance().total = boarding(confirmed+unconfirmed) + offchain; during settlement the boarding UTXO is still unspent in getCoins() while its freshly-minted preconfirmed VTXO is already counted, so total double-counts the refill until getCoins() drops the spent UTXO.

Fix: headline balance is now available + recoverable (= total minus boarding.total) in both fetchBalance() and the swap-event handler, so a refill enters the balance once, at settlement. Refill rows render as "Pending" until settlement promotes them to a settled "Refill" row, and the detail screen (resolveTxDisplayState) is kept in parity. A dedup guard prevents one refill from showing as both settled and pending if the SDK feeds momentarily disagree.

Matches the reference wallets (../wallet preconfirmed:!settled, ../trixie-wallet headline = available).

…-chain detail

Settled swaps are emitted as enriched native Ark legs (type 'bitcoind_tx',
synthetic 'ark-' id) that carry the swap's invoice payload. TransactionListItem
routed taps by type, so these missed the invoice branch and fell through to the
on-chain TransactionStatus screen. Route on 'payment_request' presence instead, in
both onPress and the long-press Details path, so enriched legs reach LNDViewInvoice
while refills and pure Ark transfers (no payload) keep the on-chain detail.

LNDViewInvoice gains an amount fallback to abs(value): an enriched leg has no 'amt',
so the settled success view would otherwise render 0 sats.

Locks the data contract with four unit assertions: enriched settled swaps carry
payment_request; refill rows do not.