Phase 5/6 polish: end-session flow, notif sound on API 33+, Xendit webview

Customer end-of-session (figma §6):
- PricingBottomSheet: ghost "cukup, akhiri sesi" CTA + dedup divider
- chat_screen._runEndSessionFlow chains ConfirmEndStep1 → ConfirmEndStep2
  → ClosingMessageSheet (or "lewati saja" → close + /home). The four
  popup/sheet widgets already existed; this commit just wires them
- showModalBottomSheet: showDragHandle=false to suppress the Material 3
  auto-injected handle that was stacking with our own pill

Notification sound on API 33+:
- Bump channel halobestie_chat_v1 → halobestie_chat_v2, created from
  native Kotlin in MainActivity.kt with AudioAttributes contentType
  CONTENT_TYPE_SONIFICATION. flutter_local_notifications' default of
  CONTENT_TYPE_UNKNOWN was causing Android 13 to silently drop audio
  focus while the notification still posted (isNoisy=true). Both apps
- Backend FCM payload channelId updated to v2
- AndroidManifest meta-data: default_notification_icon + color → brand
  silhouette tinted pink instead of generic Android bell. Both apps

Customer pairing reliability:
- pairing_notifier: applyPairedFromPush({sessionId, mitraName}) unsticks
  searching screen when WS push failed and FCM/active-session-poll is
  the first signal. Idempotent across PairingSearchingData,
  PairingTargetedWaitingData, PairingErrorData (covers ALREADY_ACTIVE)
- notification_service: dispatches every FCM data payload to an
  onDataMessage callback (foreground + tap + cold-start). main.dart
  wires that to applyPairedFromPush on type=='paired'. Foreground
  'paired' no longer renders a local banner — screen self-advances
- main.dart activeSession listener also calls applyPairedFromPush when
  a session appears server-side while pairing is in a waiting state.
  Covers stale ALREADY_ACTIVE recovery without a full page refresh

Auth refresh token race:
- auth_notifier._refreshFromStorage shares a single in-flight Future
  across all callers (Auth.build + 401-retry path). Backend rotates
  refresh tokens, so concurrent callers using the same stored token
  would race → loser 401s → catch wipes flutter_secure_storage → user
  appears logged out after kill+reopen

Polish:
- method_pick_screen: resizeToAvoidBottomInset=false — prevents the
  one-frame overflow when entering with the previous screen's keyboard
  still animating out
- bestie_history: BestieHistoryItem now carries `status` (backend
  already returns it). Removed _rawHistoryProvider that fetched the
  same endpoint just to read status; the two providers could go out
  of sync mid-rebuild and throw RangeError(length) on indexing

Xendit Stage 8 (carried from WIP):
- xendit_checkout_screen: embedded webview hosting Xendit's invoice
  page (intercepts halobestie:// deeplink + return-page URLs for
  deterministic pop)
- waiting_payment_screen: auto-pushes the webview when the backend
  payload includes xendit_invoice_url; spinner card + "Buka ulang
  halaman pembayaran" CTA for the QR-fallback path
- pubspec: webview_flutter ^4.13.0

Maestro infra:
- subflows/onboarding_returning_user: drop the "Mulai" carousel wait
  (splash auto-advances since 2026-05-26); tap phone-field hint
  instead of point; drop hideKeyboard (sends BACK → /home when the
  IME isn't actually up)
- New flow ts-customer-06-01-end_session_via_timeup_sheet: drives
  the full path to the chat-expired banner. Last step blocked by a
  Maestro+Flutter gesture quirk on the perpanjang ElevatedButton
  (raw `adb input tap` works at the same coords). Documented in
  memory; deeplink fixture or manual verify recommended
- ChatExpiredBanner button wrapped with Semantics(identifier:
  'chat_extend_button', button: true, onTap: …) — good hygiene for
  future tests even though it doesn't fix the dadb tap issue

.dev/: tracked wsl_emulator_bridge.ps1 + wsl_tcp_relay.py for
Maestro-on-WSL setup (Windows-side netsh portproxy + WSL-side
loopback relays). Both referenced from existing CLAUDE.md notes.

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

client_app/lib/main.dart

@@ -11,6 +11,7 @@ import 'core/auth/token_storage.dart';
 import 'core/chat/active_session_notifier.dart';
 import 'core/chat/chat_notifier.dart';
 import 'core/notifications/notification_service.dart';
+import 'core/pairing/pairing_notifier.dart';
 import 'core/theme/halo_theme.dart';
 import 'firebase_options.dart';
 import 'router.dart';
@@ -101,6 +102,17 @@ class _AppState extends ConsumerState<App> with WidgetsBindingObserver {
           notifier.connectedSessionId != sessionId) {
         notifier.connectIfNotConnected(sessionId);
       }
+      // If pairing is still in a waiting state on resume, the `paired` push
+      // may have landed while we were backgrounded and the user came back
+      // via the app icon (no tap → no _navigateFromMessage). Force a fresh
+      // activeSession fetch so the listener below can advance the pairing
+      // state from the server's truth.
+      final pairingState = ref.read(pairingProvider);
+      if (pairingState is PairingSearchingData ||
+          pairingState is PairingTargetedWaitingData) {
+        // ignore: discarded_futures
+        ref.read(activeSessionProvider.notifier).refresh();
+      }
     }
   }
 
@@ -153,6 +165,25 @@ class _AppState extends ConsumerState<App> with WidgetsBindingObserver {
       }
       if (_appPaused) return;
       final sessionId = snapshot.sessionId;
+      // Recovery: if pairing is still in a waiting state (or stuck in
+      // ALREADY_ACTIVE error from a stale in-flight session) but the server
+      // already has us in an active session, the WS `paired` event was lost
+      // (FCM fallback fired and the customer didn't tap, OR we missed it
+      // mid-reconnect, OR the new chat-request was blocked by a pre-existing
+      // session that the mitra has since accepted). Advance the pairing state
+      // from the polled snapshot so the searching screen unsticks.
+      if (sessionId != null) {
+        final pairingState = ref.read(pairingProvider);
+        if (pairingState is PairingSearchingData ||
+            pairingState is PairingTargetedWaitingData ||
+            pairingState is PairingErrorData) {
+          // ignore: discarded_futures
+          ref.read(pairingProvider.notifier).applyPairedFromPush(
+                sessionId: sessionId,
+                mitraName: snapshot.mitraName,
+              );
+        }
+      }
       if (sessionId != null && notifier.connectedSessionId != sessionId) {
         notifier.connectIfNotConnected(sessionId);
       }
@@ -160,7 +191,26 @@ class _AppState extends ConsumerState<App> with WidgetsBindingObserver {
 
     final router = ref.watch(routerProvider);
 
-    NotificationService.initialize(router);
+    NotificationService.initialize(
+      router,
+      onDataMessage: (data) {
+        // FCM `paired` arrived (likely because the backend's WS push
+        // couldn't find the customer's socket). Advance the pairing
+        // notifier so the searching screen navigates without requiring
+        // the user to tap the notification.
+        if (data['type'] == 'paired') {
+          final sessionId = data['session_id'] as String?;
+          if (sessionId == null) return;
+          final mitraName =
+              (data['mitra_display_name'] as String?) ?? 'Bestie';
+          // ignore: discarded_futures
+          ref.read(pairingProvider.notifier).applyPairedFromPush(
+                sessionId: sessionId,
+                mitraName: mitraName,
+              );
+        }
+      },
+    );
 
     return MaterialApp.router(
       title: 'Halo Bestie',