fix: SCA review round + gitea pipeline green — GDPR audit scrub, backend test gaps, frontend SCA/Square-API, docs parity

7 review agents (pipeline run, self-review, codebase-context, frontend-placement,
backend testing-gaps, Square-API, docs-parity) audited the SCA-primary work.
ALL findings fixed, including every pre-existing red CI job:

GDPR (HIGH):
- anonymize_user() now scrubs admin_audit_log.target_user_id (mirrors
  delete_guest_user) so 2fa_fallback_charge rows (customer id + card_last4 PII)
  no longer survive registered-user account deletion; gdpr test added

BACKEND TEST GAPS (all 10):
- delivery-unavailable 503 branch: prod-tag predicate test + dev-variant marker
- twoFactorFallbackEnabled alias/case/default matrix tests + exported wrapper
- insertTwoFAFallbackAudit details-JSON shape + audit-row assertions for all
  6 gate sites (booking/tip/gift-card/payment-method/terminal/till, both actors)
- CreateTerminalPayment.VerificationToken: passthrough, too-long 400, 2FA-skip,
  token-less fallback + SCA-required (new terminal_sca_test.go)
- isVerificationRequiredError at all 5 charge sites (402 + code:verification_required)
- customer_initiated handler-level assertions (MIT false admin / CIT true customer)
- Mock: ApprovePendingVerification, ChallengeResult auto/deny, _deny token suffix,
  parseVerifyToken unit tests

FRONTEND SCA + Square-API (CRITICAL):
- tokenizeSavedCardWithVerification reads result.token (the verified token) not
  result.verificationResult (deprecated verifyBuyer shape — saved-card SCA could
  never succeed in production before); parseTokenizeVerificationResult pure fn
  extracted + pinned in square.test.ts; 'verified' with no token proceeds tokenless
- HIGH: saved-card idempotency key regenerated after a definitive 402 (fresh token
  under the same key = IDEMPOTENCY_KEY_REUSED dead-loop); kept on 503/cancelled
- challenge-cancelled copy no longer promises a 2FA fallback the UI doesn't show;
  'waiting for approval in your banking app' state on CIT surfaces
- sca-unavailable demotion resets per attempt; card selection disabled mid-challenge;
  genuine saved-card declines no longer relabeled 'requires verification';
  modal-close guard during processing; retry affordance standardized

PIPELINE (every red job now green):
- prod-tag build break fixed (shared square stub + test_helpers_test.go, prod-safe)
- govulncheck: x/image 0.45.0 bumped (x/text resolved); go mod tidy clean
- race: TestDeleteAccount_InvalidatesSquareCustomerCache made deterministic
- DAV_ADMIN_PASSWORD placeholder in .env.example (compose config passes)
- frontend: prettier 28 files, eslint, a11y 38 errors, knip (currentZIndex),
  deps in-range, audit vulns (nanoid/postcss) — all fixed; 67 vitest cases

DOCS PARITY (6 DRIFTs + 5 GAPs): payments doc Ch4/Ch14/Appendix A, Technical
Manual 2FA + counter-reset + payment sections, README test counts + SNAPSHOT_ENC_KEY,
Feature Catalog, .env.example REQUIRE_2FA — SCA-primary/2FA-backup posture verified
against code everywhere

Verified: 26/26 dev + 24/24 prod packages, both vet tags, golangci-lint/staticcheck/
gosec 0 on both tags, gitleaks clean, 2,464 backend + 67 frontend tests.

.env.example

@@ -55,18 +55,23 @@ SQUARE_ENVIRONMENT=mock
 # deliberately route a dev build to the real production API. Never set in a
 # deployed production build.
 SQUARE_ALLOW_REAL_API=
-# 2FA — merchant-level authorization gate on saved-card online payments (NOT
-# PSD2 SCA; Square buyer verification is the SCA mechanism and is wired for
-# new-card charges). Kept as an additional fraud control until Square buyer
-# verification is wired for saved-card charges. Enforcement is FAIL-CLOSED:
+# 2FA — backup merchant-level authorization gate on saved-card online payments.
+# NOT PSD2 SCA: Square buyer verification (3-D Secure / SCA) is the PRIMARY
+# authorisation for saved-card charges and is wired for both new-card and
+# saved-card charges. The 2FA gate fires only when SCA is unavailable (e.g. a
+# customer's bank does not support the in-app approval flow) and every such
+# fallback charge is audited (admin_audit_log 2fa_fallback_charge). Enforcement
+# is FAIL-CLOSED:
 # ON unless REQUIRE_2FA explicitly disables it (false/0/off/no, case-insensitive)
 # OR SQUARE_ENVIRONMENT explicitly equals one of mock/dev/development/test.
 # Empty or unknown SQUARE_ENVIRONMENT values are treated as production-enforced
 # (a mistyped env var can never silently disarm the gate; the backend logs a
 # startup warning in that case). Set REQUIRE_2FA=false only in controlled
 # environments.
-# Code delivery: there is NO email/SMS transport yet. The verification code is
-# delivered via the server log (a [2FA]-prefixed line). In enforced/production
+# Code delivery: the intended channel is email/SMS (the method chosen at
+# setup) — NOT wired yet. Until it lands, the verification code is delivered
+# via the server log (a [2FA]-prefixed line) when the operator opts into
+# TWO_FACTOR_ALLOW_LOG_DELIVERY=true (see below); in enforced/production
 # environments an operator must relay the logged code to the user out-of-band;
 # the API never returns the code while enforcement is ON.
 REQUIRE_2FA=true
@@ -136,9 +141,11 @@ DAV_BASE_URL=http://localhost:8080
 # DAV_ADMIN_PASSWORD — REQUIRED, FAIL-CLOSED. sabredav/server.php refuses to
 # start when unset or set to a known weak/default value ('admin' etc.) — this
 # server exposes customer PII vCards, so no public default credential is ever
-# acceptable. Generate a strong random value:
+# acceptable. The placeholder below satisfies compose validation only; it MUST
+# be replaced before any deployment (compose.yml fails fast via
+# ${DAV_ADMIN_PASSWORD:?} if it is ever unset). Generate a strong random value:
 #   openssl rand -hex 32
-DAV_ADMIN_PASSWORD=
+DAV_ADMIN_PASSWORD=changeme-admin-password
 
 # Logging
 # Set to "true" to disable ANSI color escape sequences in log output