Bug/year end numbers (#744)

* fix(bookkeeping): allow creating a fiscal year that fills an interior gap

Fiscal-period creation only allowed chaining a new räkenskapsår before the
earliest or after the latest existing period, so a company with a gap between
years (e.g. 2024 + 2026 from an SIE import, missing 2025) could not create the
missing year — it failed with "New period must chain before the earliest or
after the latest existing period".

Generalise forward chaining onto the new period's immediate predecessor, which
covers both appending a new latest year and filling an interior gap. The
"prior year must be locked" guard now applies only to true appends, not gap
fills (a backfill, like backward chaining). previous_period_id is set to the
predecessor and the successor is relinked so the BFNAR 2013:2 continuity chain
stays intact. The create dialog suggests the missing year (capped so it never
overlaps the next period), the settings page seeds the dialog at the earliest
gap, and the default suggested name is now "Räkenskapsår <year>".

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(bookkeeping): omföra föregående års resultat (2099 → 2098) at year-end

Year-end closing posts the result to 2099 "Årets resultat" and the opening
balance carried it forward on 2099 every year, so 2099 accumulated across
years and the prior result never moved off "Årets resultat".

executeYearEndClosing now posts a separate "Omföring av föregående års
resultat" verifikat (Dr 2099 / Cr 2098 for a profit, reversed for a loss)
into the new period after the continuity check passes, so 2099 starts each
year at zero. Kept as a standalone entry rather than folded into the opening
balance so the IB stays a faithful mirror of the prior UB and IB/UB
continuity still holds. Aktiebolag only; idempotent; no-op when 2099 is flat.
The 2098 → 2091/2898 disposition (bolagsstämma decision) is intentionally
left to a separate step.

- new source_type 'result_appropriation' (migration + type + Zod enum)
- generateResultAppropriation helper (planner + poster) wired as step 11
- ResultStep surfaces the omföring voucher
- unit tests + pg-real invariant
- scripts/repair-result-appropriation.ts: retroactive catch-up (dry-run default)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(transactions): shadow-detect date-drift duplicate bank transactions

The content-dedup bridge buckets on exact (date, ore), so the same
transaction re-imported with a booking date that drifted a day lands in
a different bucket and slips past every dedup layer. Add a measure-only
("shadow") detector that flags would-be +/-1-day duplicates and counts
them, without changing what is inserted - so the gap can be validated on
real data before any enforcement, mirroring the scope-drift shadow.

- shiftIsoDate(): pure, deterministic adjacent-date helper
- ingest: DEDUP_DATE_DRIFT_MODE flag (default on), pre-loop bucket
  snapshot, per-row gate with desc-bridge + cross-channel-symmetry
  signals; logs shadow_date_drift_candidates, never alters inserts
- fail-safe date guard so the measurement can never abort an import
- regression tests for both signals, account/window/distinct guards,
  no-double-count, and the malformed-date fail-safe

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(bookkeeping): anonymize a customer reference in fiscal-period tests

Remove a real customer name ("AXMD AB") from regression-test comments;
no logic change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(workflows): enhance Docker image scanning and caching mechanisms

* fix(bookkeeping): enhance year-end result appropriation handling and error reporting

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

supabase/migrations/20260627120000_journal_source_type_result_appropriation.sql

@@ -0,0 +1,37 @@
+-- Migration: add 'result_appropriation' to journal_entries.source_type CHECK
+--
+-- Year-end closing posts the net result to 2099 "Årets resultat", and the
+-- opening-balance entry carries every class 1-2 account forward verbatim —
+-- so 2099 was re-opened on 2099 each year and the prior result accumulated
+-- there instead of being moved off "Årets resultat". The new
+-- generateResultAppropriation() helper posts a separate year-open omföring
+-- (Dr 2099 / Cr 2098 for a profit) in the new period so 2099 starts each
+-- year at zero. That verifikat uses source_type='result_appropriation';
+-- this migration adds the value to the DB allowlist so the insert is not
+-- rejected with PG 23514. The TS type (JournalEntrySourceType) and the Zod
+-- schema (JournalEntrySourceTypeSchema) are updated in the same change.
+--
+-- See 20260623120000 for the previous expansion pattern. We preserve all
+-- pre-existing source_type values and append the new one.
+
+ALTER TABLE public.journal_entries
+  DROP CONSTRAINT IF EXISTS journal_entries_source_type_check;
+
+ALTER TABLE public.journal_entries
+  ADD CONSTRAINT journal_entries_source_type_check
+  CHECK (source_type IN (
+    'manual', 'bank_transaction', 'invoice_created',
+    'invoice_paid', 'invoice_cash_payment', 'credit_note', 'salary_payment',
+    'opening_balance', 'year_end',
+    'storno', 'correction', 'import', 'system',
+    'inbox_item',
+    'supplier_invoice_registered', 'supplier_invoice_paid',
+    'supplier_invoice_cash_payment', 'supplier_credit_note',
+    'currency_revaluation',
+    'supplier_invoice_privately_paid',
+    'reminder_fee',
+    'accrual',
+    'result_appropriation'
+  ));
+
+NOTIFY pgrst, 'reload schema';