fix(invoices): bank match stores the applied amount, not cash received, in invoice_payments (#2277)

* fix(invoices): bank match stores the applied amount, not cash received, in invoice_payments

The dashboard match-invoice route, its v1 twin and the pending-operation
match_transaction_invoice executor wrote invoice_payments.amount as the
cash received in invoice currency. When a whole-krona bank line settles an
öre-carrying remaining (the customer pays the rounded "Att betala"),
planInvoicePayment advances paid_amount by the remaining only and books
the öre on 3740, so the row exceeded the receivable by the absorbed öre:
remaining 999.60, bank 1 000.00 gave a 1 000.00 row against a 999.60
paid_amount. The kontantmetod cut-off then pushed a -0.40 receivable with
negative scaled moms, the historical AR ledger showed -0.40 outstanding
on a paid invoice, and a storno of the payment voucher restored
paid_amount 0.40 off (issue #2250).

PR #2236 defined the amount for the manual, MCP and Stripe paths as the
amount APPLIED to the invoice (new paid_amount minus the prior one). The
three bank-match paths now share that definition through one helper,
appliedPaymentAmount() in lib/invoices/invoice-payment-row.ts, which
recordInvoicePaymentRow() uses as well. Every other field of the row
(payment date, currency, exchange rate, journal entry, bank transaction,
notes) is unchanged. Without a residual the applied amount equals the
cash received, so ordinary matches post identical rows; cross-currency
rows are now öre-rounded like paid_amount instead of the 4-decimal spot
conversion, so row and paid_amount agree.

Existing rows carrying the overshoot are not repaired here; that is a
separate call.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015qgLgdt4mLmha1ZLFMwq1u

* refactor(invoices): one writer for invoice_payments rows

Rework of the #2250 fix from first principles. The bank-match paths did
not just get the amount wrong; the class of bug is that invoice_payments
rows were hand-built at five product sites (dashboard bank match, its v1
twin, the pending-operation match, the link-to-existing-voucher flow, and
the #2236 paths through the helper), each computing its own fields with
no single definition of what the row means.

recordInvoicePaymentRow() (lib/invoices/invoice-payment-row.ts) is now the
one writer. Its options grew by what the bank paths set, all optional with
today's defaults so the #2236 callers are unchanged: transactionId
(default null), exchangeRate (the rate actually used; omitted =
invoice.exchange_rate, explicit null stored as null) and notes (default
null). The failure result carries the Postgres SQLSTATE so the routes keep
mapping a unique violation (23505) exactly as before. The applied-amount
formula is an internal detail of that file again.

Routed through the writer: app/api/transactions/[id]/match-invoice, the
v1 match-invoice twin, commitMatchTransactionInvoice in
lib/pending-operations/commit.ts, and lib/transactions/link-journal-entry.ts
(strict plan, same currency only: its amount is unchanged, it now shares
the row semantics). The pending-operation path used to drop the insert
error on the floor; it stays non-fatal but is logged with ids.

Guard: scripts/checks/no-new-antipatterns.mjs gains
direct-invoice-payment-insert, a file-set rule with no baseline (0 today):
.from('invoice_payments').insert( or .upsert( anywhere under app/, lib/ or
extensions/ outside lib/invoices/invoice-payment-row.ts fails
npm run check:guards. Operator scripts under scripts/ are out of its scope
on purpose.

Tests: the writer's unit tests cover the new options, the explicit-null
rate, the SQLSTATE passthrough and the öre-rounded prior-paid
subtraction; the per-path 3740 tests from the first commit stand; mock
insert slots now return the row id the writer selects back.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015qgLgdt4mLmha1ZLFMwq1u

---------

Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

lib/transactions/link-journal-entry.ts

@@ -17,6 +17,7 @@ import type { SupabaseClient } from '@supabase/supabase-js'
 import { eventBus } from '@/lib/events/bus'
 import { clearSettledInvoiceSuggestions } from '@/lib/invoices/clear-settled-invoice-suggestions'
 import { paidAtFromDate } from '@/lib/invoices/paid-at'
+import { recordInvoicePaymentRow } from '@/lib/invoices/invoice-payment-row'
 import { logMatchEvent } from '@/lib/invoices/match-log'
 import { propagateUnderlagForBookedTransaction } from '@/lib/transactions/inbox-underlag'
 import { hasBankLineJunctionRow } from '@/lib/transactions/is-booked'
@@ -389,22 +390,30 @@ export async function linkTransactionToJournalEntry(
     // reporting.
     const paymentExchangeRate = transaction.exchange_rate ?? null
 
-    const { error: paymentInsertError } = await supabase
-      .from('invoice_payments')
-      .insert({
-        user_id: userId,
-        company_id: companyId,
-        invoice_id: invoiceId,
-        payment_date: transaction.date,
-        amount: transaction.amount,
+    // The AR sub-ledger row goes through the single writer
+    // (lib/invoices/invoice-payment-row.ts). This path plans strictly (no öre
+    // absorption, same currency only), so the applied amount IS the bank line
+    // to the öre: the writer is used for one set of row semantics, not for a
+    // different number. A unique violation (23505) means the row already
+    // exists for this voucher and is not an error here.
+    const recorded = await recordInvoicePaymentRow(supabase, {
+      userId,
+      companyId,
+      invoice: {
+        id: invoiceId,
         currency: invoice.currency,
-        exchange_rate: paymentExchangeRate,
-        journal_entry_id: journalEntryId,
-        transaction_id: transactionId,
-        notes: 'Kopplad till befintlig verifikation (ingen ny bokföring skapad)',
-      })
+        exchange_rate: invoice.exchange_rate,
+        paid_amount: invoice.paid_amount,
+      },
+      paymentDate: transaction.date,
+      newPaidAmount,
+      journalEntryId,
+      transactionId,
+      exchangeRate: paymentExchangeRate,
+      notes: 'Kopplad till befintlig verifikation (ingen ny bokföring skapad)',
+    })
 
-    if (paymentInsertError && paymentInsertError.code !== '23505') {
+    if (!recorded.ok && recorded.code !== '23505') {
       const { error: invRevertErr } = await supabase
         .from('invoices')
         .update({