Session expiry, arrival geofence guard, multi-destination stops

Three fixes found by running the app on a real handset against production.

1. An expired token left the app looking signed in and unable to work.
   MilerApi.onUnauthorized was declared and called on every 401 but never
   assigned, so the token was dropped and nothing else happened: the profile
   stayed on disk, logged_out stayed false, and the rider saw his own name over
   a dashboard whose every call returned 401. He reads that as "no work today".
   The teardown now lives in endSession() and both ways out of a session — the
   Log out button and the 401 path — use it.

2. Arrived was written locally even when the rider was not there.
   updateArrivedStatus answers false for three different things and the caller
   treated all of them as "the write did not land", which is only true of one.
   A geofence refusal and a server refusal now stop the rung and hand back the
   reason; a dead network still advances, as it should.

3. A multi-destination customer pickup collapsed onto one stop.
   GET /miler/bookings returns a row per destination once collected, all with
   the same bookingid and reference. Every local store keys on that id, so the
   accepted store deduped two of three drops away and their consignment ids
   were unrecoverable. orderid is now the stop key; bookingreference stays the
   booking's name. Cards show "Stop 2 of 3" and the receiver's own name and
   number rather than the sender's.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EqVJPB9B4QuieZnBAAKgYQ

android/app/src/main/AndroidManifest.xml

@@ -4,9 +4,17 @@
     <!-- ===== Permissions ===== -->
     <uses-permission android:name="android.permission.CAMERA" />
     <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />
-    <!-- For older Android versions -->
-    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
-    <uses-permission android:name="android.permission.PICTURE_IN_PICTURE" />
+    <!-- For older Android versions. Capped at 32: from 33 READ_MEDIA_IMAGES
+         above is the permission that governs this, and requesting broad storage
+         on a modern device is both ineffective and a Play review flag. -->
+    <uses-permission
+        android:name="android.permission.READ_EXTERNAL_STORAGE"
+        android:maxSdkVersion="32" />
+    <!-- android.permission.PICTURE_IN_PICTURE was declared here and does not
+         exist. PiP is enabled by android:supportsPictureInPicture on the
+         activity, which is set below; the OS ignores the bogus name, but Play's
+         listing shows every declared permission and an unrecognised one invites
+         a reviewer's question we have no answer to. -->
     <!-- Android 13+ notifications -->
     <uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
     <uses-permission android:name="android.permission.VIBRATE" />
@@ -19,15 +27,43 @@
     <!-- Location permissions -->
     <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
     <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
-    <!-- Optional: needed for background tracking (break auto-refresh, etc.) -->
-    <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
-    <!-- Phone call (for tap-to-call customer / pickup) -->
-    <uses-permission android:name="android.permission.CALL_PHONE" />
+    <!-- ACCESS_BACKGROUND_LOCATION was declared here and REMOVED 2026-09-16.
+         The app never asked for it: `LocationPermission.always` and
+         `Permission.locationAlways` appear nowhere in lib/, and every call site
+         is a plain `Geolocator.requestPermission()`, which requests
+         while-in-use. So the declaration bought nothing and cost a great deal —
+         Play treats background location as a high-risk permission requiring a
+         declaration form, a prominent in-app disclosure, a privacy-policy
+         clause and a video walkthrough of the feature that justifies it. There
+         is no such feature.
+
+         On-duty tracking keeps working: it runs inside the foreground service
+         declared below, which is the supported pattern and needs only
+         FOREGROUND_SERVICE_LOCATION plus the while-in-use grant. -->
+    <!-- CALL_PHONE was declared here and REMOVED 2026-09-16. Every "call the
+         customer" control in the app builds `Uri(scheme: 'tel', path: …)` and
+         hands it to `launchUrl`, which is ACTION_VIEW — it *opens the dialer*
+         with the number filled in and the rider presses the green button.
+         CALL_PHONE is only needed to place a call directly with ACTION_CALL,
+         which this app never does. Declaring it asks the rider to grant the
+         app the ability to dial without him, for a feature that does not
+         exist. -->
     
     <!-- Alarm permissions for shift end (works even when app is killed) -->
     <uses-permission android:name="android.permission.INTERNET" />
+    <!-- SCHEDULE_EXACT_ALARM stays: it is user-grantable, and both alarm call
+         sites already check `alarmManager.canScheduleExactAlarms()` and fall
+         back to `setAndAllowWhileIdle` when it is refused (MainActivity.kt:256,
+         ShiftEndReceiver.kt:140).
+
+         USE_EXACT_ALARM was declared beside it and is REMOVED 2026-09-16. It is
+         a *restricted* permission: Play grants it only to apps whose core
+         function is an alarm clock, calendar or timer. A shift-end reminder is
+         none of those, so it is a policy rejection waiting to happen — and
+         because of the fallback above, removing it costs at most a few minutes
+         of drift on the end-of-shift notification when the rider has not
+         granted exact alarms. -->
     <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
-    <uses-permission android:name="android.permission.USE_EXACT_ALARM" />
     <uses-permission android:name="android.permission.WAKE_LOCK" />
 
     <!-- ===== Application ===== -->
@@ -135,10 +171,6 @@
             <action android:name="android.intent.action.VIEW" />
             <data android:scheme="tel" />
         </intent>
-        <intent>
-            <action android:name="android.intent.action.CALL" />
-            <data android:scheme="tel" />
-        </intent>
         
         <!-- Allow launching turn-by-turn navigation / maps for "Start pickup"
              (Android 11+ requires declaring these to resolve the intents). -->