Phase 4 checkpoint: chat-screen perf refactor + retryable blast-failure + repo-wide dispose-ref guardrail

Chat-screen performance (customer + mitra):
- Parent screens have zero `ref.watch` — only `ref.listen` for side effects
- Body extracted into its own `ConsumerStatefulWidget`; AppBar parts split
  into narrow `.select` consumers (mode, sensitivity, timer)
- Per-second timer ticks routed to dedicated providers
  (`chatRemainingSecondsProvider` + new `mitraChatRemainingSecondsProvider`)
  so WS `session_tick` frames don't invalidate the rest of the chat state

Dispose-in-ref bug fix:
- `home_screen.dart`, `payment_screen.dart`, `mitra_chat_screen.dart` —
  ref-using cleanup moved from `dispose()` to `deactivate()`. Modern
  Riverpod invalidates `ref` the moment `dispose()` runs; the resulting
  silent error corrupts the widget-tree finalize and the next screen
  appears frozen
- `halo_lints` package added at repo root with `no_ref_in_dispose` rule
  to catch this pattern in CI / IDE analysis
- `custom_lint` activated in both apps' `analysis_options.yaml`
  (was installed but never wired in — also brings `riverpod_lint`'s
  `avoid_ref_inside_state_dispose` online)
- CLAUDE.md Pitfalls section added to client_app + mitra_app

Phase 4 §3 retryable blast-failure (Option A):
- Backend `expirePairingRequest` + all-rejected use
  `recordIntermediateFailure` instead of `failPaymentSession` so the
  payment session stays `confirmed` for re-blast
- WS `pairing_failed` payload carries `is_terminal: false` on the
  retryable paths; client parses the flag and exposes `retryBlast()`
- "Coba cari lagi" CTA on S7 Timeout now re-blasts on the same payment
- Pairing service test updated to reflect the new semantics

Customer waiting-payment screen navigation patch:
- `_navigateTerminal` uses `Future.microtask` + `addPostFrameCallback`
  redundancy after a release-mode bug where polling stopped but
  `context.go` never fired, leaving the screen visually stuck on
  "menunggu pembayaran"

See requirement/resume-2026-05-15.md for next-day pickup checklist
(mitra release rebuild + S21 Ultra install + retest is the gating item).

Bundles unrelated in-flight Phase 4 §2.x work that was already on disk
(ESP screen removal, USP one-time gate scaffolding, bestie-availability
public route, OTP service edits, Maestro flow tweaks) — kept together
to avoid a partial-rebase mess.

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

client_app/lib/core/pairing/pairing_notifier.dart

@@ -30,9 +30,14 @@ class PairingSearchingData extends PairingData {
   /// the payment-session-scoped cancel endpoint without re-prompting.
   final String paymentSessionId;
 
+  /// Carried so a retryable PAIRING_FAILED can preserve the customer's original
+  /// topic choice when looping back into Blast via retryBlast().
+  final TopicSensitivity topicSensitivity;
+
   const PairingSearchingData({
     required this.sessionId,
     required this.paymentSessionId,
+    required this.topicSensitivity,
   });
 }
 
@@ -105,13 +110,26 @@ class PairingTargetedUnavailableData extends PairingData {
   });
 }
 
-/// Terminal pairing failure — payment session is in `failed_pairing`. Routes
-/// to the failed-pairing screen (no_bestie_screen).
+/// Pairing failure surfaced on the S7 Timeout screen.
+///
+/// `isRetryable=true` means the backend kept the payment session `confirmed`
+/// (audit-only failure) so the customer can re-blast on the same payment via
+/// `retryBlast()`. `isRetryable=false` means the payment is in `failed_pairing`
+/// and any retry must start from a fresh payment session.
 class PairingFailedData extends PairingData {
   final PairingFailureCause cause;
   final String? paymentSessionId;
+  final bool isRetryable;
+  // Carried so retryBlast() can re-issue the blast with the customer's original
+  // topic choice. Null when the failure originated before any topic was known.
+  final TopicSensitivity? topicSensitivity;
 
-  const PairingFailedData({required this.cause, this.paymentSessionId});
+  const PairingFailedData({
+    required this.cause,
+    this.paymentSessionId,
+    this.isRetryable = false,
+    this.topicSensitivity,
+  });
 }
 
 class PairingCancelledData extends PairingData {
@@ -156,6 +174,7 @@ class Pairing extends _$Pairing {
       state = PairingSearchingData(
         sessionId: sessionId,
         paymentSessionId: paymentSessionId,
+        topicSensitivity: topicSensitivity,
       );
     } on DioException catch (e) {
       _cleanup();
@@ -279,6 +298,7 @@ class Pairing extends _$Pairing {
       state = PairingSearchingData(
         sessionId: sessionId,
         paymentSessionId: paymentSessionId,
+        topicSensitivity: topicSensitivity,
       );
     } on DioException catch (e) {
       _cleanup();
@@ -302,6 +322,25 @@ class Pairing extends _$Pairing {
     state = const PairingInitialData();
   }
 
+  /// "Coba Cari Lagi" CTA on the S7 Timeout screen when the payment was kept
+  /// `confirmed` (retryable failure). Re-blasts on the same payment session.
+  ///
+  /// Caller should only invoke this when `state is PairingFailedData &&
+  /// state.isRetryable && paymentSessionId != null && topicSensitivity != null`.
+  Future<void> retryBlast() async {
+    final current = state;
+    if (current is! PairingFailedData
+        || !current.isRetryable
+        || current.paymentSessionId == null
+        || current.topicSensitivity == null) {
+      return;
+    }
+    await startSearch(
+      paymentSessionId: current.paymentSessionId!,
+      topicSensitivity: current.topicSensitivity!,
+    );
+  }
+
   // ---- Internal ---------------------------------------------------------
 
   Future<void> _connectWebSocket() async {
@@ -348,13 +387,20 @@ class Pairing extends _$Pairing {
     }
 
     if (type == WsMessage.pairingFailed) {
-      // Terminal — payment_session is in failed_pairing server-side.
       final causeTag = data['cause_tag'] as String?;
       final paymentSessionId = data['payment_session_id'] as String?;
+      // Missing flag = terminal (backward-compat with older emit sites). When
+      // false, the backend kept the payment confirmed and we can re-blast.
+      final isRetryable = data['is_terminal'] == false;
+      final carriedTopic = current is PairingSearchingData
+          ? current.topicSensitivity
+          : null;
       _cleanup();
       state = PairingFailedData(
         cause: PairingFailureCause.fromString(causeTag),
         paymentSessionId: paymentSessionId,
+        isRetryable: isRetryable,
+        topicSensitivity: carriedTopic,
       );
       return;
     }