feat(transactions): select and bulk-ignore any unbooked skattekonto row (#2127) (#2140)

* feat(transactions): select and bulk-ignore any unbooked skattekonto row (#2127)

Skattekonto rows in the inbox only got a checkbox when they carried a
deterministic booking suggestion, because the only bulk action was
Bokför valda. A migration backlog on the skattekonto (rows from before
the first fiscal year, history already booked via SIE) therefore had
to be ignored one row at a time, while bank rows next to them could be
bulk-ignored.

- isSkvSelectable: every unbooked, non-ignored skattekonto row is
  selectable (checkbox, shift-range, Markera alla).
- Bulk Bokför keeps its eligibility rule: button count, confirmation
  summary and submit all read one skvBookableSelectedRows list, so a
  mixed selection books only the deterministic subset.
- Bulk Ignorera now spans bank + skattekonto selections: one
  confirmation (body names where each kind is restored), one progress
  counter, one toast, bank rows via POST /transactions/:id/ignore and
  skattekonto rows via the per-row PATCH .../ignore, 5-wide.
- The bank-only confirm/toast strings move from hardcoded Swedish to
  transactions.batch_ignore_* keys (sv + en).

Bullet 2 of the issue (unbooked skattekonto rows "not in att göra after
migration") is scoped out; see DECISIONS.md.

Closes #2127

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

* feat(transactions): warn when bulk Ignorera covers rows that look like affärshändelser

Compliance review on #2140: any unbooked skattekonto row can now be
bulk-ignored, including rows with a deterministic booking suggestion
(interest, charges) that BFL 5 kap. says should be booked. The ignore
stays allowed, a migrated backlog is exactly such rows already present
in the imported books, but the confirmation now says how many of the
selected rows carry a suggestion and no duplicate hint, and what
Ignorera is for.

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

---------

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

DECISIONS.md

@@ -1457,6 +1457,8 @@ One line per decision: `[YYYY-MM-DD] <decision>: <why>`. Appended by agents and
 [2026-09-01] F2 bank-data staleness: ship freshness reads only (last_synced_at/consent_expires/error_message on gnubok_connect_bank + new GET /api/v1/.../bank-connections, scope companies:read mirroring the MCP mapping): the daily cron already syncs server-side, so visibility is what the incident lacked; an agent-triggerable sync is a product bet (EB call cost, runaway agents) and was deferred by Emil.
 [2026-09-01] Verifikationsserie in the Ny verifikation modal is a closed dropdown instead of a one-letter free-text field: a typo there silently opens a brand-new series with its own number sequence, and the letters only mean anything if everyone uses the same ones. The letters are NOT prescribed by law (BFL 5 kap. 7 § requires only unbroken systematic numbering within each series), and the incumbents disagree: Björn Lundén uses A Huvudserie, F Kundfakturor, I Inbetalningar, L Leverantörsfakturor, N Löner, U Utbetalningar, J Bokslut. We ship FORTNOX's table verbatim (A Redovisning, B Kundfakturor, C Inbetalningar från kunder, D Leverantörsfakturor, E Utbetalningar till leverantörer, F Kassa, G Avskrivning, H Periodisering, I Bokslut, J Revisor, K Lön, L Kontantfaktura, M Momsrapport), from their own Systemdokumentation, because Fortnox is the system most companies migrate here from and an imported ledger should keep its meaning. REJECTED an earlier draft that labelled A as Kundfakturor: A is the general series manual entries land in (the one point Fortnox and BL agree on, and Fortnox allows manuell kontering ONLY in A), and migration 20260526120700 ships every source_type defaulting to 'A', so every existing company's A series already holds everything. Calling it Kundfakturor would mislabel their entire history and the modal's own default. The list is closed but any letter the company already configured, or that a draft was saved with, is appended so no existing value can fall out of the picker. Also: tabbing or clicking into an untouched amount field now proposes the outstanding difference (pre-selected, so typing replaces it) when the row already has an account and the difference belongs on that side. This deliberately reverses part of the note in updateLine that said a balancing amount must never auto-fill: that note was about filling on ACCOUNT selection, which stole the amount before the user had a chance to split it. Filling on focus keeps the split case intact because the proposal is selected text, and it fixes the common moms case where the last line is just the remainder.
 [2026-09-01] Settings PUT cross-field VAT validations scoped to touched field groups (vat-completeness, 40m-monthly, periodisk sammanstallning), not fixed at onboarding: partial saves from surfaces without VAT fields (invoice bank-details dialog) were hard-blocked by pre-existing vat_registered-without-number state (Marketio Lab case). The invariant still holds on every save that touches its group; explicit null now counts as a clear instead of falling back to the stored value during validation. Onboarding-side VAT number collection left as follow-up.
+[2026-09-01] #2127 skattekonto bulk: every unbooked, non-ignored skattekonto row in the inbox is selectable (isSkvSelectable); bulk Bokför keeps re-filtering through isSkvBulkEligible (button count, summary and submit read one skvBookableSelectedRows list) and bulk Ignorera spans bank + skattekonto selections in one confirmation, calling the per-row PATCH .../ignore 5-wide since no batch endpoint exists. Bullet 2 of the issue (unbooked skattekonto rows "not in att göra after migration") is scoped out: neither Hem's Att göra (lib/worklist book_transaction) nor the nav badge counts skattekonto_transactions, by construction of the canonical predicate, while the inbox itself lists them regardless of date. Whether skattekonto rows join the Att bokföra count is a founder call; reply asks the reporter where they looked.
+[2026-09-01] #2128 (row checkbox always visible) left open, no PR: #2093 (merged the same morning, after the Discord report) already made CHECKBOX_REVEAL_CLASS rest at opacity-50 with border-foreground and go solid on hover/focus/checked/coarse pointer, on all 8 list surfaces. The literal ask (fully solid at rest) is a one-token change to that constant but a design change across every list page, so it stays with the founder rather than being bumped in a bug-fix batch.
 [2026-09-01] #2126 payment-account-missing wording: made the message currency-aware on the client (getErrorMessage branch on details.currency via describeMissingInvoicePaymentAccount) plus a currency-neutral rewrite of the registry entry, instead of threading messageSv/messageEn through the nine server emit sites: every dashboard caller already sends details.currency, API/MCP consumers get the clarified registry text (names bankgiro/plusgiro/Swish for SEK, IBAN otherwise), and the staged-operation commit path (bare string) calls the helper directly. The reporter saw the pre-#2088 text; #2088 added the Inställningar -> Fakturering pointer the same evening, this removes the "valutakonto" reading.
 [2026-08-24] Declined to enable Peppol access for Low-Stack Technologies (enskild firma, personnummer-based org nr): both send validation and receive registration deliberately refuse personnummer identifiers (GDPR; DIGG recommends 0088 GLN) and no GLN support exists, so enabling would only surface errors; request row left as 'requested' pending founder call.
 [2026-08-26] invoice@arcim.io email unblock (Jakob's own test account, EXECUTED on prod, never re-run): the in-app delete had already anonymized + banned tombstone 7086c4d1 at 06:48 UTC, but the tombstone keeps auth.users.email by design (2026-07-24), which blocks re-signup. Replicated the 2026-07-30 Orback pattern: email scrambled to anonymized+<uuid>@tombstone.invalid, the stale auth.sessions row deleted, AND the Google auth.identities row (sub 103263015636623485631) deleted rather than scrubbed: an OAuth identity matches on (provider, provider_id), not email, so a scrubbed email alone would have re-bound the next Google sign-in to the banned tombstone. Hard delete of auth.users was never an option: companies.created_by cascades and the 4 154 posted CashLeads Media AB entries are BFL 7 kap. 2 § retained (delete_user_account was dropped in 20260706100000 for exactly this). The 3 archived companies stay as an inert tenant with 0 members.