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/core/pairing/pairing_notifier.dart

@@ -186,7 +186,17 @@ class Pairing extends _$Pairing {
           paymentRequestId: paymentRequestId,
         );
       } else if (code == 'ALREADY_ACTIVE') {
-        state = const PairingErrorData('Kamu sudah memiliki sesi aktif.');
+        // Stale in-flight session/request on the backend. The session may
+        // already have flipped to ACTIVE (mitra accepted the previous
+        // attempt while this new request was in-flight) — refresh now so
+        // the activeSession listener in main.dart can advance us out of
+        // this error without waiting for the next 15s poll tick. If the
+        // pre-existing session is still SEARCHING / PENDING_ACCEPTANCE,
+        // the next poll that surfaces an ACTIVE session will trigger the
+        // same recovery via applyPairedFromPush(PairingErrorData → ...).
+        state = const PairingErrorData('Kamu sudah memiliki sesi aktif. Menyambungkan...');
+        // ignore: discarded_futures
+        ref.read(activeSessionProvider.notifier).refresh();
       } else {
         state = const PairingErrorData('Gagal memulai. Coba lagi.');
       }
@@ -322,6 +332,43 @@ class Pairing extends _$Pairing {
     state = const PairingInitialData();
   }
 
+  /// Out-of-band "paired" signal — fired when the backend's WS push to the
+  /// customer failed and the FCM fallback (or a post-resume activeSession
+  /// refresh) is the first thing to inform us that pairing succeeded.
+  ///
+  /// Mirrors the WS `paired` branch in `_onWsEvent`: drops the WS+countdown,
+  /// flashes `BestieFoundData` for ~2s, then settles into `ActiveData`.
+  /// Idempotent — bails when we already know about this sessionId (so a
+  /// foreground FCM + activeSession-poll race doesn't double-fire).
+  ///
+  /// Also accepts [PairingErrorData] as a valid prior state: the
+  /// `ALREADY_ACTIVE` recovery path lands the notifier in error while the
+  /// pre-existing session is still pending acceptance on the backend, and the
+  /// activeSession poll is what eventually surfaces the paired session.
+  Future<void> applyPairedFromPush({
+    required String sessionId,
+    required String mitraName,
+  }) async {
+    final current = state;
+    if (current is PairingBestieFoundData && current.sessionId == sessionId) return;
+    if (current is PairingActiveData && current.sessionId == sessionId) return;
+    if (current is! PairingSearchingData &&
+        current is! PairingTargetedWaitingData &&
+        current is! PairingInitialData &&
+        current is! PairingErrorData) {
+      return;
+    }
+    _cleanup();
+    state = PairingBestieFoundData(sessionId: sessionId, mitraName: mitraName);
+    // ignore: unawaited_futures
+    ref.read(activeSessionProvider.notifier).refresh();
+    await Future.delayed(const Duration(seconds: 2));
+    if (state is PairingBestieFoundData &&
+        (state as PairingBestieFoundData).sessionId == sessionId) {
+      state = PairingActiveData(sessionId: sessionId, mitraName: mitraName);
+    }
+  }
+
   /// "Coba Cari Lagi" CTA on the S7 Timeout screen when the payment was kept
   /// `confirmed` (retryable failure). Re-blasts on the same payment session.
   ///