plans: names docs late credit ledger

plans/names-codes/2026-10-09-name-codes.md

@@ -525,7 +525,7 @@ Migration `20261010_names` runs in SQLite and Postgres. The badge tables (`sx_ba
   - A row found applied on chain with no receipt for any of its hashes is `mined`, with no hash known to have mined.
   - The service answers identical repeats from the table after a restart. The per-name cap counts its rows of the last hour.
 - **`sx_badge_service_name_transactions`:** the registration or edit, `kind` (commit, register, edit), `raw`, `tx_hash`, `registrar_nonce`, `sent_at`, `mined_block`, `status`. The sender resumes from the rows with no receipt.
-- **`sx_badge_service_name_invoices`:** `invoice_id`, `registration_id`, `provider_ref`, `late_credited` (the cents of a late payment already credited to the order's balance). Payments gain `confirmed_amount` (confirmed money only, only rising), which the late credit reads.
+- **`sx_badge_service_name_invoices`:** `invoice_id`, `registration_id`, `provider_ref`, `late_alerted_at`. Payments gain `confirmed_amount`, `confirmed_crypto` and `invoice_rate` (confirmed money only, only rising). Each late credit is a `name_late_credits` row with the confirmed crypto, the invoice's and the current rate, the lower one used, and the cents (owner, 2026-10-22: the lower of the two rates).
   - Today's invoice queries are badge-only. So each of these gains this table: `GET /api/invoice/:id`, cancel, settlement, the poller's unpaid and overdue scans and its expiry update, and the lookups by `provider_ref`.
   - Settling a name invoice queues its registration, instead of requiring a code hash. This happens in the transaction that marks the invoice paid; the invoice's and the registration's changes are published to the long poll only after that commit. It applies only to an invoice still open.
   - An invoice settled after it expired or was canceled leaves its registration `unpaid` and credits its confirmed money to that order's balance. Its order page and history row say "Paid after the invoice closed; kept as your balance", with Use and Refund.

plans/names-codes/2026-10-09-names-web-store-plan.md

@@ -581,7 +581,7 @@ An order carries the name's hash and length, the duration, the owner address, th
     - A row found applied on chain with no receipt for any of its hashes is `mined`, with no hash known to have mined.
     - The service answers identical repeats from the table after a restart, and the per-name cap counts its rows.
   - **`name_transactions`:** `registration_id` or the edit's id, `kind` (commit, register, edit), `raw`, `tx_hash`, `registrar_nonce`, `sent_at`, `mined_block`, `status`. The sender resumes from the rows with no receipt.
-  - **`name_invoices`:** `invoice_id`, `registration_id`, `provider_ref`, `late_credited` (the cents of a late payment already credited to the order's balance). The amount is the invoice's own. Payments gain `confirmed_amount` (confirmed money only, only rising), which the late credit reads.
+  - **`name_invoices`:** `invoice_id`, `registration_id`, `provider_ref`, `late_alerted_at`. The amount is the invoice's own. Payments gain `confirmed_amount`, `confirmed_crypto` and `invoice_rate` (confirmed money only, only rising). Each late credit is a `name_late_credits` row with the confirmed crypto, the invoice's and the current rate, the lower one used, and the cents (owner, 2026-10-22).
   - **The badge tables are untouched**, so there is no table rebuild.
   - **Invoice queries:** today's are badge-only, so each gains the name side.
     - The queries: the shared `invoiceRowSelect` (inner-joined to `badge_code_invoices` and `badge_codes`); `qGetInvoice`, behind `GET /api/invoice/:id`, cancel and settlement (`settlementInvoice`); the poller's `qUnpaidRefs`, `qOverdueInvoices` and `qExpireOverdue` (whose update requires a `badge_code_invoices` row); and the lookups by `provider_ref`.