Replace standalone payment comments surface with unified Get Paid transaction history

[BullishNode]

Problem

Get Paid home currently exposes a standalone Lightning payment comments card and routes to a separate comment-history screen. That is the wrong product model: comments are optional data attached to received payments, not a separate Get Paid product.

The wallet's current invoice list is also invoice-specific. It does not yet present successful Lightning Address payments alongside wallet-created, Donation Page, and Point of Sale payments.

Desired UX

Use one Get Paid transaction-history list for the merchant's received payments.

The list should include:

• Successful Lightning Address payments, with or without payer comments.
• Successful merchant-created invoice payments.
• Donation Page payments.
• Point of Sale payments.
• Late payments attributable to an original invoice.
• Payment-evidenced transactions that are still settling, shown with an honest pending state when appropriate.

The list should exclude:

• Abandoned Lightning Address comment intents.
• Unpaid or expired invoices with no payment evidence.
• Failed attempts.
• Unfunded quotes and payment instructions.

Tapping a row opens one payment/invoice detail screen. The detail shows amount, received time, source, payment rail, settlement state, invoice relationship when applicable, and the optional payer comment. A missing comment is normal and must not produce an empty comments section.

The user must never see intentId, internal Bullnym identifiers, or separate comment-history navigation.

Required mobile changes

• Consume the new Bullnym unified Get Paid transaction-history contract through a typed Bullnym client/domain model.
• Add a typed transaction-history facade/use case at the correct feature boundary.
• Replace the invoice-list-only data model where needed with a unified received-payment model, while retaining invoice-specific fields for invoice-backed rows.
• Map unknown source/status values safely and fail closed.
• Preserve pagination, refresh, loading, empty, retry, and partial-failure behavior.
• Render payer comments as escaped plain text only.
• Keep comments out of logs, analytics, public URLs, and shareable invoice content.
• Remove the Get Paid dashboard comments card and separate comment-history route/screen from the product flow.
• Ensure invoice-backed detail retains existing status, fallback, settlement, late-payment, and payment-event behavior.
• Do not match comments to payments by amount, timestamp, payer name, or list position; use the server-provided stable identifier/relationship.

Acceptance criteria

• Get Paid home contains no standalone comments card.
• One history list displays successful payments from all supported sources.
• A successful Lightning Address payment without a comment appears.
• A successful Lightning Address payment with a comment appears once.
• The comment appears only on the tapped transaction detail.
• Abandoned comment intents do not appear.
• Unpaid invoices do not appear in the payment-only history.
• Invoice-backed rows preserve their invoice detail and fallback behavior.
• Late and settlement-pending states are displayed honestly.
• Pagination and pull-to-refresh are stable.
• Loading, empty, server error, invalid response, and retry states are covered.
• Unknown transaction source/status cannot crash the app or create a falsely successful display.
• No internal intent or server identifiers are visible in user-facing UI.
• Widget, cubit/use-case, contract, and integration tests cover the complete behavior.

Out of scope

• Rich text or clickable links in comments.
• Comment search, moderation, editing, or a standalone comment inbox.
• Local persistence of payer comments unless explicitly required by the payment-history design.
• Changing invoice creation or payment flows.

Dependency

This issue depends on the Bullnym server exposing the unified authenticated transaction-history contract. Until then, do not try to join the existing invoice list and comments endpoint heuristically.

[BullishNode]

Implemented in the correct stacked branches and left unmerged:

• Mobile PR [Get Paid 2 44/50] Unified Get Paid transaction history #126 adds the dedicated Get Paid Transactions card, signed client, history list/detail UX, optional payment comments, honest settlement states, and separate route names. The Invoices card opens invoice creation directly from PR [Get Paid 2 30/50] Get Paid dashboard hub #112.
• Bullnym PR Get Paid: unified transaction history bullnym#195 adds the authenticated /api/v1/get-paid/transactions resource and schema 066.

Both active PRs are draft/open. The server no longer treats comments as the transaction resource.

[BullishNode]

Done in the current stack. The standalone comments surface is fully removed (no card, route, or usecase remnants in lib/ or test/), and the unified Get Paid transaction history covers all four sources (GetPaidTransactionSource: lightningAddress, invoice, paymentPage, pointOfSale) with per-transaction payer comments rendered on the detail card and an honest pending/settled/problem settlement state. Completed across the history work and the unified transaction card (PR #152).