fix(mobile): pre-demo fixes — QR/approve swallowed-401, session expiry, NFC, hide Add-card

[ahmetabdullahgultekin]

Pre-demo (demo 2026-06-03) mobile fixes. Additive + reversible. Do NOT merge/deploy yet — review first, then trigger the signed CI APK build. Each fix was verified against origin/main before changing.

#1 + approve-login — swallowed-401 false "APPROVED" (root of "approved on phone, browser waits forever")

QrLoginApiImpl.approveSession and ApproveLoginApiImpl.decide POSTed without reading the response, unlike their sibling calls. A non-2xx (e.g. an expired bearer → 401/403) was silently swallowed: the phone flipped to APPROVED while the server session stayed PENDING and the originating (web) login never advanced.

• Both now throw ResponseException(response, ...) on a non-success status, with the status code in the message so the shared ErrorMapper maps it to a user message.
• The 401 case now also triggers the transparent refresh+retry from Claude/review module plan 014p edzxv bqfib2 grp pjhx6 r #2, so a stale-but-refreshable bearer recovers automatically instead of false-approving.
• Files: shared/.../api/QrLoginApiImpl.kt (approveSession, ~L33), shared/.../api/ApproveLoginApiImpl.kt (decide, ~L25).

#2 — session dies after ~15 min

• NetworkModule.kt: the refresh-on-401 HttpResponseValidator could not re-fire the failed request (its own TODO) → the first call after the 15-min access-token lifetime surfaced as a logout. Replaced with an HttpSend interceptor (part of ktor-client-core — no new dependency; the project deliberately avoids ktor-client-auth, see desktopApp/.../RefreshInterceptor.kt) that refreshes under the existing rotation mutex and retries the original request once with the fresh bearer. Refresh logic extracted to a reusable refreshAccessToken() helper.
• TokenManager.kt: isAuthenticated() checked token presence only; now tolerates an expired access token when a refresh token exists (decodes the JWT exp claim via base64url + kotlinx.serialization; fail-open for non-JWT tokens). A returning user is no longer bounced to login when a silent refresh is possible.

#7 — NFC won't read (OS detects card, app stays "ready to scan")

• Removed the foreground TECH_DISCOVERED intent-filter + nfc_tech_filter meta-data from AndroidManifest.xml so reader mode wins over the system tag-dispatcher.
• Relaxed AndroidNfcService.processTag (~L173): previously dropped a tap unless state was exactly WaitingForCard; now only rejects a tap while a read is already in flight (Reading).
• ⚠️ NOT verifiable without a physical device — needs on-device adb logcat confirmation before being trusted for the demo. Fully reversible (comments document how).

#8 — "Add card" dead-end

• Hidden the DashboardScreen "Add card" QuickAction. CardScanScreen is a camera photo wizard that never uploads/persists. Screen + nav route left intact; uncomment to restore once OCR/upload backend exists.

Verification

• :shared:compileDebugKotlinAndroid ✅ · :androidApp:compileDebugKotlin + processDebugMainManifest ✅
• New tests: QrApproveLoginStatusCheckTest (6) + TokenManagerAuthExpiryTest (4) — all pass.
• Full shared unit suite (forced rerun): 489 tests, 0 failures, 0 errors.
• Build host cannot run an emulator, so Fingerprint Frontend #7's runtime behaviour is unverified by design.

Still needs on-device verification

• Fingerprint Frontend #7 NFC — both the manifest change and the state-guard relaxation are best-effort and require adb logcat on a real device with a real chip before the demo. Treat live chip-read as not-demo-safe until confirmed.

🤖 Generated with Claude Code