[Due for payment 2026-10-15] [CFI][FE 2/7] Payment history: render the payment history table rows #101829

Sub-task of [CFI] Add a "View payment history" page with historical billing receipts and monthly user activity.

Goal

The page shows a table of all past payments — one row per bill, newest first, with the billing period, the amount, and an incl. tax indicator where sales tax was charged.

Scope

• Read the purchase list from Onyx (ONYXKEYS.PURCHASE_LIST) and render the rows.
• Extend the Onyx type. src/types/onyx/PurchaseList.ts currently declares only amount, created, currency, message, and purchaseID. None of the fields these pages need are declared — the purchase type, the receipt identifier, the sales-tax flags, and the back-pointer identifiers that FE 3/7 needs. Add them as part of this PR.
• Exclude non-bill records from the table. Refunds, disputes, and balance transfers are their own purchase records that point back at the bill they modify. They must not render as standalone rows. (Folding them onto their parent to derive the badge is FE 3/7; this issue only needs them filtered out.)
• Table text must be user-selectable and copyable. CSV export was cut from scope specifically on the basis that the table is copyable, so this is a requirement, not a nicety.
• Empty state when there are no purchases; skeleton while the list is loading.
• Copy in every src/languages/*.ts locale.

Acceptance criteria

• One row per billed period, sorted newest first.
• The amount renders in the purchase's own currency using the app's currency formatting.
• incl. tax appears only when sales tax was actually charged and the account is not tax-exempt.
• No refund / dispute / balance-transfer record appears as its own row.
• Text in the table can be selected and copied on web.
• Renders correctly wide and narrow.

Depends on

The backend PR that pushes the full purchase list to Onyx (tracked in a separate internal issue). Until that lands, only the most recent purchase is in Onyx — build against the agreed payload shape, not against what is pushed today.

Easy to get wrong

• Showing the active-user count next to the amount. This was explicitly rejected in design review: a 40-seat annual commitment billed in full with only 25 users active does not add up, and pairing the two numbers creates support volume. The count belongs under the Activity header (FE 5/7).
• Treating the purchase list as a mergeable object. It is an array, so Onyx replaces it wholesale rather than merging entries.