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>

backend/src/services/payment.service.js

@@ -26,6 +26,7 @@
 //
 //   on(eventName, handler) → subscribe to lifecycle events
 //   verifyWebhookToken(headerToken) → constant-time compare for webhook auth (used by route)
+//   xenditInvoiceMethodFromCode(payment_code) → catalog→Xendit invoice filter map (exported for tests)
 //
 //   registerPairingSubscriber() → wires pairing.service as a subscriber to payment_request.confirmed
 //   recordIntermediateFailure(...) → audit-only failure for flows with a fallback path
@@ -87,8 +88,54 @@ const xenditClient = () => {
   return _xenditClient
 }
 
-const createXenditInvoice = async ({ paymentRequestId, amount, ttlMinutes, description }) => {
+// Map our catalog `payment_code` (Xendit channel-code style — `BCA_VIRTUAL_ACCOUNT`,
+// `CARDS`, etc., per https://docs.xendit.co/docs/available-payment-channels) to the
+// short token Xendit's Create-Invoice `paymentMethods[]` filter expects. The two
+// vocabularies overlap a lot but are not identical — channel codes are descriptive
+// (`BCA_VIRTUAL_ACCOUNT`), invoice filter values are by-payment-rail (`BCA`).
+//
+// Returning null means "no mapping" — caller should omit `paymentMethods` so Xendit
+// shows the full multi-method picker (graceful degradation). Avoid throwing here —
+// a stray unknown code shouldn't break invoice creation.
+//
+// Reference list (Xendit Create Invoice `payment_methods` accepted values, May 2026):
+//   Bank: BCA, BNI, BRI, BSI, BJB, MANDIRI, PERMATA, SAHABAT_SAMPOERNA
+//   Retail: ALFAMART, INDOMARET
+//   E-wallet: OVO, DANA, SHOPEEPAY, LINKAJA, JENIUSPAY, ASTRAPAY
+//   QR: QRIS    Card: CREDIT_CARD    Paylater: KREDIVO, AKULAKU, UANGME, ATOME
+//
+// Notes:
+// - CIMB is NOT exposed by Xendit's invoice paymentMethods filter (only as a raw VA
+//   channel via the lower-level VA API), so CIMB_VIRTUAL_ACCOUNT intentionally
+//   returns null → multi-method page fallback.
+export const xenditInvoiceMethodFromCode = (code) => {
+  if (!code || typeof code !== 'string') return null
+  const m = {
+    QRIS: 'QRIS',
+    OVO: 'OVO',
+    DANA: 'DANA',
+    SHOPEEPAY: 'SHOPEEPAY',
+    LINKAJA: 'LINKAJA',
+    ASTRAPAY: 'ASTRAPAY',
+    BCA_VIRTUAL_ACCOUNT: 'BCA',
+    BNI_VIRTUAL_ACCOUNT: 'BNI',
+    BRI_VIRTUAL_ACCOUNT: 'BRI',
+    BSI_VIRTUAL_ACCOUNT: 'BSI',
+    MANDIRI_VIRTUAL_ACCOUNT: 'MANDIRI',
+    PERMATA_VIRTUAL_ACCOUNT: 'PERMATA',
+    BJB_VIRTUAL_ACCOUNT: 'BJB',
+    BSS_VIRTUAL_ACCOUNT: 'SAHABAT_SAMPOERNA',
+    ALFAMART: 'ALFAMART',
+    INDOMARET: 'INDOMARET',
+    CARDS: 'CREDIT_CARD',
+  }
+  return m[code.toUpperCase()] ?? null
+}
+
+const createXenditInvoice = async ({ paymentRequestId, amount, ttlMinutes, description, preferredPaymentCode }) => {
   const { successRedirectUrl, failureRedirectUrl } = getXenditConfig()
+  const invoiceMethod = xenditInvoiceMethodFromCode(preferredPaymentCode)
+  console.log('[xendit] createInvoice', { paymentRequestId, amount, preferredPaymentCode, invoiceMethod })
   const inv = await xenditClient().Invoice.createInvoice({
     data: {
       externalId: paymentRequestId,             // D4 — our UUID is the Xendit external_id
@@ -101,7 +148,10 @@ const createXenditInvoice = async ({ paymentRequestId, amount, ttlMinutes, descr
       // Stamped so a shared webhook router (no DB access) can route v1 vs v2 traffic
       // purely from the echoed payload. Keep this string stable — it is a routing key.
       metadata: { app: 'halobestie_v2' },
-      // paymentMethods omitted → honor dashboard config (operator picks methods without a deploy)
+      // Lock the hosted page to the customer's chosen method when we have a mapping.
+      // When mapping returns null (unknown / unsupported code), omit the filter and
+      // let Xendit show the full picker so the customer can still pay.
+      ...(invoiceMethod ? { paymentMethods: [invoiceMethod] } : {}),
     },
   })
   return { invoiceId: inv.id, invoiceUrl: inv.invoiceUrl }
@@ -177,10 +227,10 @@ export const requestPayment = async ({
   isExtension = false,
   targetedMitraId = null,
   // Customer's pre-picked payment method from the catalog. Optional;
-  // upper-cased Xendit channel code (e.g. `OVO`). Stamped onto
-  // product_metadata for analytics + future use as a Xendit `paymentMethods`
-  // filter. Not currently passed to Xendit invoice creation — the customer
-  // re-picks on Xendit's checkout page.
+  // upper-cased channel code (e.g. `OVO`, `BCA_VIRTUAL_ACCOUNT`, `CARDS`).
+  // Stamped onto product_metadata for analytics AND translated via
+  // xenditInvoiceMethodFromCode() into Xendit's invoice paymentMethods[]
+  // filter so the customer doesn't have to re-pick on the hosted page.
   preferredPaymentCode = null,
 }) => {
   if (!customerId) {
@@ -239,6 +289,7 @@ export const requestPayment = async ({
         amount: row.amount,
         ttlMinutes: ttl,
         description: buildInvoiceDescription(row),
+        preferredPaymentCode,
       })
       await sql`
         UPDATE payment_requests