docs(loyalty): add Android terminal E2E tests to user-journeys checklist

The web user-journey checklist (Tests 1–8) only covers human-using-loyalty
flows from a browser. The cashier-facing Android tablet built in Phases
A–F goes through a different surface and has its own failure modes that
won't surface in any web test. Adding 6 dedicated Android tests so a
tablet-in-hand verification has the same level of structure as the web
side.

- Test 9: Tablet pairing — QR scan + manual entry fallback, with the
  audit (paired-device row appears, last_seen_at populated)
- Test 10: PIN screen — wrong/right PIN, offline-capable bcrypt verify,
  locked-PIN rejection
- Test 11: Daily flows — search, scan, enroll, stamp, earn, redeem,
  with the acting_terminal_device_id audit column check at the end
- Test 12: Offline queue + sync — airplane mode → queued → re-online →
  drain; redeem is hard-disabled offline per spec
- Test 13: Auto-lock + manual lock — 2 min idle, immediate lock button,
  the known caveat that AlertDialog pointer events don't bubble
- Test 14: Device revocation — revoke on web → 401 on tablet next call

Updated the go-live readiness snapshot to reference these as Step 6b
(gated on user obtaining a tablet, not on schedule).

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

docs/proposals/loyalty-go-live-readiness.md

@@ -24,7 +24,8 @@ non-blocking).
 | 3 | Database migrations | ✅ | All four module heads current incl. `loyalty_011` (acting-device audit) on prod |
 | 4 | FR/DE/LB translations for analytics i18n keys | 🟡 | 8 keys still EN-only. Cosmetic, doesn't block soft launch |
 | 5 | `messaging.manage_templates` permission for store owners | 🟡 | Only matters if merchants self-edit templates. Admin can edit centrally. Defer |
-| 6 | 8 user-journey E2E tests | ⏳ | **The remaining gate** — user does this with a real test customer |
+| 6 | 8 web user-journey E2E tests | ⏳ | **The remaining gate** — user does this with a real test customer |
+| 6b | 6 Android terminal E2E tests | ⏳ | Pairing, PIN, daily flows, offline queue, auto-lock, device revoke — gated on user obtaining a tablet |
 | 7 | Google Wallet real-device pass test | ✅ | Already confirmed earlier — cards register, points/redeem visible on personal Google Wallet |
 | 8 | Go live | ⏳ | Gated by #6. Cleanup test data + enable platform feature flags for FASHIONHUB |
 | 9 | Google Wallet production access | ⏳ | Post-launch, 1–3 day Google review. App-side change is zero; same issuer + service account, passes become public-visible once approved |
@@ -94,9 +95,14 @@ In priority order:
    locale). `loyalty_enrollment`, `loyalty_welcome_bonus` and
    `loyalty_reward_ready` are the customer-visible ones — adjust
    subject lines + body copy if anything reads off-brand.
-2. **Walk the 8 user-journey E2E tests** — checklist at the bottom of
+2. **Walk the 8 web user-journey E2E tests** — checklist at the bottom of
    `app/modules/loyalty/docs/user-journeys.md`. Use a personal email
    as the test customer.
+2b. **Once a tablet is on hand: walk the 6 Android terminal tests** —
+   same doc, "Android Terminal Tests" section (Tests 9–14). Covers
+   pairing (QR + manual), offline PIN bcrypt verify, daily flows
+   (stamp/earn/redeem/enroll), offline queue drain, idle auto-lock,
+   and device revocation cutoff.
 3. **Flip live for FASHIONHUB** — clean any test data, double-check
    Celery (`docker compose ps | grep celery`), enable loyalty feature
    on FASHIONHUB's stores via the admin UI.