Add backend-authoritative invoice draft editing (ADR 0006/0007)

Move the invoice draft editor to a backend single source of truth: an
in-memory InvoiceDraftSession (per-token, cached) holds the editable payload,
server-computed sums/VAT and validation, plus an automatic change history. The
browser posts single edits; the server recomputes and signals the editing
session over a dedicated SignalR hub (DraftPreviewHub) to re-fetch.

This reverses the previously-documented stateless editor (EVAL_live_invoice_editing,
INVOICE_LIFECYCLE §10), by explicit product decision — captured in ADR 0006 and 0007
plus the live-draft-editing concept doc.

Backend (this milestone):
- InvoiceDraftSession + ChangeHistoryEntry data holders
- InvoiceDraftCalculator: pure port of quantChange/invSumUpdate (§13b, VAT-by-rate)
  and consistency checks — fully unit-tested
- IInvoiceDraftCache/InvoiceDraftCache: in-memory store with idle sliding TTL
- IInvoiceDraftService/InvoiceDraftEditService: open (payload or DB reload), patch,
  build state, flush via existing RegisterInvoiceAsync (no new persistence), preview
  from cache, discard (DB reload), history
- InvoiceDraftExpiryService: pre-expiry warning + eviction-with-reason
- DraftPreviewHub + IDraftNotifier/DraftNotifier: targeted draftReady/draftExpiring/
  draftClosed signals per draft token
- inv/dopen|dstate|dpatch|dpreview|dsave|dhistory|ddiscard|dclose endpoints; save
  reports success/failure via the existing EventService
- DI + hub mapping in Program.cs

Frontend (additive foundation): $fis.draft SignalR client for /draftpreview.
The editor DOM inversion (routing deltas, rendering from server state) is the
next, separately-verified step; existing endpoints are unaffected.

Tests: 30 new (calculator, cache, expiry, patch/history, flush); 306 total passing.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Fuchs/Docs/EVAL_live_invoice_editing.md

@@ -1,5 +1,17 @@
 # Evaluation — Backend-cached invoice editing over SignalR
 
+> **⚠️ Superseded (2026-07-10).** This note's recommendation (keep the editor
+> stateless; do **not** build the SignalR/server-cached model) was reversed by the
+> product owner. Invoice draft editing is now backend-authoritative over an in-memory
+> cache — see **ADR
+> [`Decisions/0006-backend-authoritative-draft-editing.md`](Decisions/0006-backend-authoritative-draft-editing.md)**,
+> [`Decisions/0007-targeted-draft-signalr-groups.md`](Decisions/0007-targeted-draft-signalr-groups.md)
+> and the concept doc [`Concepts/live-draft-editing.md`](Concepts/live-draft-editing.md).
+> The analysis below is retained for the historical rationale and the risks it flagged
+> (server-held state, scaling/backplane, reconnect) — which the new design addresses or
+> accepts explicitly as documented limitations.
+
+
 **Idea (as proposed):** hold invoices that users are editing in a **server-side
 cache**, keep a **SignalR / WebSocket** connection open, apply each front-end
 change **in the backend**, and **push the recomputed state back** to the browser.