feat(ssr): subtle fade-in on wizard step cards

§3 animations: the migrated wizard step cards had no transition, so step→step
swaps and modal open were flat. The old mm/* slide system was deleted in Phase
11 (and its classes purged from CSS), and the transaction-edit "reference" uses
an undefined `last-modal-step` no-op — so there was no clean slide to restore.

Apply the codebase's existing `fade-in transition-opacity duration-300`
primitive (`.htmx-added .fade-in` in input.css) to all three wizard step cards
(new-invoice basic-details + accounts, vendor step-card, client step-card). Each
card now fades in on open and on every step swap. Verified live: cards always
settle to opacity 1 (never stuck invisible) on both open and step navigation.

Richer directional (forward/back) slide transitions are left for a design pass.

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

docs/plans/2026-06-27-001-fix-ssr-modal-regressions-plan.md

@@ -1,7 +1,8 @@
 # SSR Modal Regression Fixes — QA Findings & Resumable Task List
 
-> **Status:** BUG A, BUG C, BUG D, BUG B, BUG E/F, and the CSS size root cause are
-> **FIXED + verified** (2026-06-27). Remaining: modal step animations (§3). Resume from §4/§3.
+> **Status:** ALL identified items **FIXED + verified** (2026-06-27) — BUG A, BUG C, BUG D, BUG B,
+> BUG E/F, the CSS size root cause, and a subtle wizard fade-in (§3). The only thing intentionally
+> left is the optional richer forward/back *slide* transition, which needs design sign-off (§3).
 > **Owner:** Bryce
 > **Branch:** `integreat-execute-refactor`
 > **Date:** 2026-06-27
@@ -92,10 +93,21 @@ animate:
 - By contrast, `dialog/success-modal-` and the Invoice Pay card (`last-modal-step transition
   duration-150`) keep transitions, so the intended pattern still exists to copy from.
 
-**FIX:** add the swap-transition classes to the wizard step cards (mirror `success-modal-`'s
-`transition duration-300 ease-in-out htmx-swapping:... htmx-added:...` string, or the lighter
-`last-modal-step transition duration-150` used by the transaction-edit card). Confirm the
-`htmx-swapping:`/`htmx-added:` custom variants survive the §2 CSS rebuild.
+**FIX — DONE (subtle fade) & verified:** added the codebase's existing `fade-in transition-opacity
+duration-300` to all three wizard step cards (new-invoice basic-details + accounts, vendor
+step-card, client step-card). `fade-in` is defined in `resources/input.css`
+(`.htmx-added .fade-in { opacity:0 }` → transitions to 1 after htmx settle), so each card fades in
+on open *and* on every step swap. Verified live: cards always settle to **opacity 1** (never stuck
+invisible) on both open and step navigation — no functional risk.
+
+Notes / intentionally deferred (needs design intent + visual sign-off, so not done autonomously):
+- The transaction-edit "reference" card's `last-modal-step` class is **undefined** (a no-op); its
+  only real transition is `transition duration-150`. So there was no clean reference slide to copy.
+- The richer **forward/backward slide** transitions (the old `mm/*` modal-stack system using
+  `group/transition` + `forward`/`backward` + `htmx-*:translate-x-2/3`) were deliberately deleted in
+  Phase 11 and purged from the CSS. Re-introducing directional slides is a larger design decision
+  (which element carries `htmx-swapping`/`htmx-added` — the form vs the card — plus settle timing)
+  and is left for a human-in-the-loop pass if the subtle fade isn't enough.
 
 ## 4. Bug list + fixes (prioritized task list)