feat(loyalty): Phase 1 production launch hardening

Phase 1 of the loyalty production launch plan: config & security
hardening, dropped-data fix, DB integrity guards, rate limiting, and
constant-time auth compare. 362 tests pass.

- 1.4 Persist customer birth_date (new column + migration). Enrollment
  form was collecting it but the value was silently dropped because
  create_customer_for_enrollment never received it. Backfills existing
  customers without overwriting.
- 1.1 LOYALTY_GOOGLE_SERVICE_ACCOUNT_JSON validated at startup (file
  must exist and be readable; ~ expanded). Adds is_google_wallet_enabled
  and is_apple_wallet_enabled derived flags. Prod path documented as
  ~/apps/orion/google-wallet-sa.json.
- 1.5 CHECK constraints on loyalty_cards (points_balance, stamp_count
  non-negative) and loyalty_programs (min_purchase, points_per_euro,
  welcome_bonus non-negative; stamps_target >= 1). Mirrored as
  CheckConstraint in models. Pre-flight scan showed zero violations.
- 1.3 @rate_limit on store mutating endpoints: stamp 60/min,
  redeem/points-earn 30-60/min, void/adjust 20/min, pin unlock 10/min.
- 1.2 Constant-time hmac.compare_digest for Apple Wallet auth token
  (pulled forward from Phase 9 — code is safe whenever Apple ships).

See app/modules/loyalty/docs/production-launch-plan.md for the full
launch plan and remaining phases.

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

app/modules/loyalty/migrations/versions/loyalty_003_add_check_constraints.py

@@ -0,0 +1,58 @@
+"""loyalty 003 - add CHECK constraints on balances and program limits
+
+Defends against direct SQL writes that would create impossible loyalty
+state (negative balances, zero stamps target, etc). The application
+service layer already clamps these values, but a database-level guard
+catches anything that bypasses the service (manual fixes, scripts, ORM
+shortcuts) before it can corrupt downstream reports and exports.
+
+Pre-flight check on the dev database showed zero existing violations
+(see Phase 1.5 of the loyalty production launch plan), so no data
+remediation is needed in this upgrade path.
+
+Revision ID: loyalty_003
+Revises: loyalty_002
+Create Date: 2026-04-09
+"""
+from alembic import op
+
+revision = "loyalty_003"
+down_revision = "loyalty_002"
+branch_labels = None
+depends_on = None
+
+
+CONSTRAINTS = [
+    ("loyalty_cards", "ck_loyalty_cards_points_balance_nonneg", "points_balance >= 0"),
+    ("loyalty_cards", "ck_loyalty_cards_stamp_count_nonneg", "stamp_count >= 0"),
+    (
+        "loyalty_programs",
+        "ck_loyalty_programs_min_purchase_nonneg",
+        "minimum_purchase_cents >= 0",
+    ),
+    (
+        "loyalty_programs",
+        "ck_loyalty_programs_points_per_euro_nonneg",
+        "points_per_euro >= 0",
+    ),
+    (
+        "loyalty_programs",
+        "ck_loyalty_programs_stamps_target_positive",
+        "stamps_target >= 1",
+    ),
+    (
+        "loyalty_programs",
+        "ck_loyalty_programs_welcome_bonus_nonneg",
+        "welcome_bonus_points >= 0",
+    ),
+]
+
+
+def upgrade() -> None:
+    for table, name, expression in CONSTRAINTS:
+        op.create_check_constraint(name, table, expression)
+
+
+def downgrade() -> None:
+    for table, name, _expression in reversed(CONSTRAINTS):
+        op.drop_constraint(name, table, type_="check")