feat(onboarding): the orgnr field also accepts a company name (#2421)

* feat(onboarding): the orgnr field also accepts a company name

The journey's first question kept asking for an organisationsnummer, and
people who do not know theirs by heart left to look it up. The same field
now takes either: digits (with dashes or spaces) run the existing orgnr
lookup unchanged; anything else with three or more characters runs a
free-text name search against the same TIC index. One hit continues
exactly as a typed orgnr would; several hits render as a chip row
"Name / orgnr / city" inside the same question, and the pick applies the
hit's already-fetched lookup result. No hits stays on the step with a note
to refine or type the number. The screen, placeholder and hint are
otherwise untouched; only the mobile keyboard changes from numeric to text.

Why the problem occurred: the lookup was keyed on the one identifier the
user is least likely to remember, while the provider index behind it is a
full-text index that already answers names.

What was removed or simplified: nothing new is stored. The TIC search
document carries every field /lookup returns, so a name hit is mapped by
the same mapper and a picked hit costs no second provider call. The reducer
gained one shared "TIC answered" transition (applyLookupFound) that the
typed-orgnr path, the single-hit path and the pick path all use, instead of
three copies of the fact-to-settings mapping.

Why this shape and not the proposed one: search-as-you-type autocomplete
would burn the 3000/mo TIC budget in days, so the search fires on Enter
only, like the orgnr lookup. Taking the top hit blind on several matches
was rejected: name ranking is fuzzy and common names or sole-trader
surnames would land on a stranger's company; a five-chip pick row is the
smallest thing that keeps the user in control. The route answers 400 under
three characters, 404 in the handler's own "Company not found" shape so the
client's existing dispatcher-vs-handler mapping applies, and every TIC
failure code maps through the same handler as /lookup.

Fixes #2418

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

* fix(onboarding): reduce Lens registration numbers to the 10-digit form for name-search hits

Skeptic pass on 1d70716a8 (issue #2418). A sole trader found by name got
Lens's 16-digit registration number (century-prefixed personnummer plus a
4-digit serial) stored as org_number; createCompany refuses anything
normalizeOrgNumber rejects, so the journey dead-ended at the last step and
the returned orgnr step could only shake. The typed-orgnr path never stored
Lens's number, so this was the first place it reached settings.

- searchCompaniesForLookup derives orgNumber through the new
  lensRegistrationToOrgNumber (16-prefixed 12 digits and the 16-digit
  enskild-firma form reduce to the 10-digit key; hits that do not
  normalize are dropped, never dead-ended).
- Sole-trader chips show "Enskild firma" and city instead of the number,
  which is the owner's personnummer.
- The name path resets the duplicate note on submit, so an earlier orgnr's
  "you already have X" no longer sits above the chip row.

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

* fix(onboarding): keep the typed name in the field after a search pick

Compliance swarm on PR #2421: writing the picked hit's org number into the
visible input printed a sole trader's personnummer in plain text on Back,
the one thing the chip row masks. The field now keeps the name the user
typed; Back re-searches it.

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

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

DECISIONS.md

@@ -1662,6 +1662,8 @@ One line per decision: `[YYYY-MM-DD] <decision>: <why>`. Appended by agents and
 [2026-09-08] #2391 skeptic pass: orgNumberKey only strips hyphens and spaces and only unprefixes 12-digit values behind 16/18/19/20. Reason: 26 prod supplier rows hold a VAT number (orgnr + 01, prefixes 55/52/87) in org_number, and 'last 10 of any 12 digits' would have rewritten them to another company's identity; letters stay because BE0123456789 is not the Swedish 0123456789. The matcher scans live suppliers only (archived_at IS NULL), the list and v1 search compare without separators, the CSV import and the provider migration orchestrator key and write through the same rule.
 [2026-09-08] correctEntry re-points the original entry's transaction_voucher_links rows to the corrected entry (lib/core/bookkeeping/storno-service.ts relinkTransactionsToEntry) instead of deleting them as issue #2364 proposed. Why: for a samlingsverifikat (bulk-book N>1) the junction is the row's only anchor, so deleting it would push rows the corrected verifikat still explains back into Att bokföra; the pointer column already follows the correction and the junction now follows it the same way, so every reader (is_transaction_booked, fetchJunctionLinkedTxIds, the bulk_book RPC) sees one live anchor. Rejected: a relink_entry_anchors RPC moving pointer and junction atomically (a migration plus pg test for a path that is already best-effort across five other statements; revisit if a partial failure ever shows up in the surfaced transactionRelinkError). Prod repair (planned, runs after merge on the founder's go; completion gets its own dated entry): the 7 stale links (3 companies) all sit on rows whose pointer names a posted entry (4 on a correction chain, 3 from a June 2026 samlingsverifikat storno that predates the junction cleanup and were re-booked 1:1); they will be re-pointed to the pointer's entry, the same rule the fix applies, rather than deleted.
 [2026-09-08] delete_last_voucher returns a correction's bank anchors (transactions.journal_entry_id and transaction_voucher_links rows) to correction_of_id before the row is deleted (migration 20260908095907). Why: the #2364 skeptic showed that once the junction follows the correction, the two-step undo (delete the correction, then the storno) cascaded the links away and restored an original that explains bank rows nobody points at, so the rows surfaced as bookable again; before, the links had stayed on the original by accident. Chosen over releasing the rows (the restored original would still explain them, same trap) and over a TS pre-step in the DELETE route (not atomic with the RPC's own guards: a refused delete would leave anchors on a reversed entry). A duplicate of a link the original already holds is dropped, not re-pointed (UNIQUE (transaction_id, journal_entry_id)).
+[2026-09-08] Onboarding name search picks via chip row, never the top hit blind: Typesense name ranking is fuzzy and common names ("Bygg AB", sole-trader surnames) make a blind pick a wrong company; five hits, active first, fired on Enter only to protect the 3000/mo TIC budget (issue #2418).
+[2026-09-08] #2418 skeptic pass: a name-search hit's org number is derived from the Lens registrationNumber via lensRegistrationToOrgNumber (16-prefixed 12 digits and the 16-digit enskild-firma form, century plus 4-digit serial, reduce to the 10-digit key; hits that do not normalize are dropped) instead of being stored as returned. Why: the typed-orgnr path never stores Lens's number, so this was the first place a 16-digit value reached settings.org_number and createCompany refused it at the last step. Sole-trader chips name the form ("Enskild firma") instead of the number, because that number is the owner's personnummer and the repo masks those everywhere else; the number still travels in the search payload since a pick has to store it.
 [2026-09-08] Medelantal anställda (Not 2, ÅRL 5:20 §) gets a whole-number override on arsredovisning_narratives (migration 20260908130127) instead of the free-text note override the support request asked for. Why: the number keeps the statutory sentence and the iXBRL MedelantaletAnstallda fact correct; free text would let a non-compliant note through and could not be tagged. One resolver (lib/salary/medelantal.ts resolveMedelantalAnstallda: override, else FTE average over employees) feeds the K2 and K3 note builders and the iXBRL input, which also reads the previous period's override so the jämförelseår column shows the same figure the previous year's document did. Rejected: rounding 0.5 up globally (silently changes every company's note and does nothing for the 148 of 195 aktiebolag with salary but no employees rows); asking the user to backdate employment_start (fixes one company, misstates the hire date).
 [2026-09-08] Issue #2413 BAS 2026 kontogrupp 12: kept 1249/1259/1269 in the catalog renamed after their free heads and dropped only 1241/1242/1251/1261, instead of removing all seven retired sub-accounts and moving the asset module's vehicle/computer defaults to BAS 2026 (1226/1224 on 1229): the asset module's DEFAULT_ACCOUNTS_BY_CATEGORY still books vehicles on 1240/1249 and computers on 1250/1259 (31 live assets in prod, guard test requires the triple in BAS_REFERENCE), so dropping the contra accounts would have forced a depreciation-default change into a label fix; that change is the founder's call and lives in #2414. The prod backfill renames only the exact catalog literal next to a free-labelled head, so old-BAS imports (1240 Bilar + 1249 Ack. avskr. bilar) and user renames stay untouched.
 [2026-09-08] Migration files must carry their own BEGIN/COMMIT when they use transaction-only statements (LOCK TABLE, SET LOCAL, SET CONSTRAINTS): CI replays each file with psql -f in autocommit and the Supabase branch runner does the same on prod, so the bare LOCK TABLE in 20260908113353 (#2413, PR #2419) failed both and stalled prod's migration queue behind it. Prod never recorded the failed version, so the file was deleted and re-issued as 20260908120449 rather than edited in place.