Waseel: driver capture, chat/calls, dispatch, and session fixes

Driver onboarding now photographs the licence, ID card and vehicle
registration and reads the credential fields off them, plus a camera-only
profile selfie riders check the arriving driver against. Adds in-app chat
and WebRTC calls, push-backed ride offers, ratings, cancellation and
payment sheets, settlement, and the owner dashboard endpoints behind them.

Camera permission on Android:
  - Declare CAMERA and READ_MEDIA_IMAGES in the manifest. expo-image-picker's
    own plugin never declares CAMERA, and Android denies a request for an
    undeclared permission instantly and silently — no dialog is ever shown,
    which is indistinguishable from the app not asking at all.
  - Handle canAskAgain: once Android stops showing the dialog, repeating why
    we need it is a dead end, so offer Open Settings instead (lib/capture-
    permission.ts), matching what the location flow already did.

Session: a 401 on a request that carried a token now ends the session
instead of being reinterpreted per-screen — driver-home had been reading it
as "this user has no driver profile" and showing an onboarding form to an
already-onboarded driver. Requests without a token are exempt so a failed
sign-in doesn't sign you out, and the notification is latched per token so
concurrent polls tear the session down once. (root) gains the auth guard
that turns that into the sign-in screen; app/index.tsx only guarded the way
in, leaving a session that ended mid-screen with nowhere to go.

Also ignore .uploads/ — it holds driver licence, ID and vehicle scans plus
profile photos, which are personal data and must not be committed.

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

constants/dispatch.ts

@@ -0,0 +1,48 @@
+// Dispatch timings and distances shared by the server engine (lib/dispatch.ts)
+// and both clients. They live here rather than in lib/dispatch.ts because that
+// module imports the database driver and can't be pulled into the bundle.
+
+/**
+ * How long a request stays open for drivers to offer on before it gives up.
+ *
+ * This is the number both sides watch: the rider sees it as "we're still
+ * looking", the driver as how long they have to decide before the job is off
+ * the board. Long enough that a driver finishing a drop-off can still take it,
+ * short enough that a rider standing on a corner at 4am gets an answer instead
+ * of a spinner.
+ */
+export const REQUEST_TTL_SECONDS = 150;
+
+/**
+ * How far a request is broadcast from the pickup point.
+ *
+ * A request is shown to every eligible driver inside this radius rather than
+ * to the nearest one at a time — the rider picks from whoever volunteers, so
+ * dispatch's job is to put the job in front of enough people to give them a
+ * real choice. Matches the default radius riders see drivers over on the map,
+ * so a rider who can see a car can be offered by that car.
+ */
+export const BROADCAST_RADIUS_M = 8000;
+
+/**
+ * Android notification channel for incoming ride requests. Created on the
+ * client with max importance, sound and vibration, and named here so the
+ * server sends to the same channel the client registered — a mismatch
+ * silently downgrades the notification to the default channel and it stops
+ * making noise.
+ */
+export const OFFER_CHANNEL_ID = "ride-offers";
+
+/**
+ * How old a driver's last position ping may be before they're treated as gone,
+ * whatever their `online` flag says. Every rider-facing query and the dispatch
+ * broadcast share this, so a driver can never be visible on the map but
+ * unreachable by a request, or vice versa.
+ *
+ * The heartbeat fires every 5s, so this is ~24 missed beats of slack. That
+ * sounds generous until you watch a real phone: Android throttles JS timers
+ * hard once the app leaves the foreground, and gaps of 20-30s were measured on
+ * a device that was awake and on screen. At 60s those gaps flickered drivers
+ * in and out of every rider's map.
+ */
+export const DRIVER_STALE_SECONDS = 120;