fix: review round — B1 clock-skew tolerance + re-poll escalation, refresh-token access-token revocation, shared 2FA composable, per-package-DB test alignment

Three fresh reviews (money/security/dup-mod) cross-validated findings:
- MEDIUM: B1 'new charge' discrimination adds a lower-bound tolerance (replayRescueLowerBoundSkew) so a retained-key replay of the ORIGINAL charge (DB clock ahead of Square) is never auto-refunded; ambiguous margins leave PENDING + CRITICAL
- MEDIUM: B1 re-poll escalates after stalePendingB1RefundAge (48h) — FAILED/REJECTED refunds go terminal (fail parent, claw back till-sale funding, CRITICAL notification); no more unbounded re-polling / stranded parents without webhooks
- DRIFT-REAL: processManualPaymentGroup now checks PENDING/FAILED/REJECTED on the synchronous refund response (mirrors processChargeGroup/manual handler) — no more premature 'completed'
- HIGH: refresh-token family kill now also invalidates the attacker's freshly-minted ACCESS token — access tokens carry a family_id claim and VerifyToken rejects tokens whose family was deleted (GenerateTokenForFamily + family-alive check); 30s grace window for concurrent two-tab refresh (no false theft alert)
- LOW: 2FA mint endpoint returns remaining_seconds; in-memory 2FA counters documented; 90-day refresh expiry single-sourced (RefreshTokenLifetime + make_interval)
- Dup/mod: NEW shared useTwoFactorCodeForSavedCard Svelte composable replaces 6 surface copies of the 2FA gate logic (Request-a-new-code added to BookingFlow + TillPurchases); account page adopts generateUUID
- Test architecture: removed t.Parallel() from 8 global-SquareClient-swapping tests per Testing Architecture doc line 89 (B1 flaky-test lesson) — fixes within-package race
- SQL alias pence rename (total_cents/paid_cents -> total_pence/paid_pence)

26/26 backend packages; 72/72 frontend tests + build; env-docs 41/41.

backend/internal/twofa/twofa.go

@@ -65,9 +65,20 @@ const MaxAttempts = 5
 const AttemptWindow = 10 * time.Minute
 
 // MaxTrackedAttempts caps the in-memory attempt map so a flood of distinct
-// user IDs cannot grow it without bound. Counters are purely in-memory (the DB
-// schema is locked — there is no attempt column), so they reset on process
-// restart; the 10-minute pending-code expiry bounds the practical impact.
+// user IDs cannot grow it without bound.
+//
+// ACCEPTED LIMITATION (LOW 6 — documentation only, no behavior change): every
+// 2FA counter here — the per-user failed-attempt count, the lockout window, and
+// the mint-cooldown stamp (AttemptState.LastMintAt, used by twoFAMintCooldown
+// in handlers/user) — is purely in-memory and resets on process restart. The
+// DB schema is locked (there is no attempt column), and the practical impact
+// is bounded by the 10-minute pending-code expiry (AttemptWindow /
+// twoFAPendingExpiry): at most one fresh 5-guess budget per 10-minute window.
+// A MULTI-INSTANCE deployment would need a shared store (e.g. a DB column or
+// Redis) for these counters, because today each instance keeps its own map —
+// an attacker could distribute guesses across instances. Single-instance
+// deployments (this app) are unaffected.
+//
 // Declared as a var so the eviction policy is unit-testable at a small cap.
 var MaxTrackedAttempts = 10_000