feat(transactions): add tested payment receipt view-model (#216)

[eleven-smg]

Closes #216

Issue

Add mobile payment success receipt

Type: Feature · Difficulty: Intermediate

Summary: Improve the payment success receipt with useful transaction details.
Current behaviour: Users may not receive enough information after a successful payment.
Expected behaviour: The success state should show recipient, amount, date, hash, and explorer link where available.
Suggested implementation: Update success screen or receipt component to display available transaction details.
Files/areas: app/, src/features/payments/, src/features/transactions/

Acceptance criteria:

• Success receipt shows transaction details.
• Transaction hash can be copied.
• Explorer link is available where configured.
• Missing data is handled gracefully.
• The UI remains non-technical.

Additional notes: Avoid raw technical payloads.

What this PR adds

A pure, framework-free receipt view-model in src/features/transactions/receipt.ts
that maps the success-screen route params to ready-to-render, non-technical
strings, plus exhaustive unit tests in __tests__/receipt.test.ts.

• buildPaymentReceipt(input) returns display-safe amount (+XLM), date,
  destination, a truncated hash for display and the full hash preserved
  for copy-to-clipboard, plus hasExplorerLink/explorerUrl driven by the
  caller's network config ("where configured").
• Graceful fallbacks: every missing/invalid field degrades to a placeholder;
  the view-model never throws.
• Non-technical UI: the displayed hash is truncated (head + tail), never the raw
  64-char payload — directly addressing "avoid raw technical payloads".
• formatReceiptAmount / formatReceiptDate / truncateHash are exported and
  independently tested. Reuses the existing formatAmount util.

Non-destructive: adds new files only; the existing payment-success screen,
helpers.ts and the feature barrel are untouched, so current tests are
unaffected. The screen can adopt this view-model incrementally.