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>

lib/driver-photo.ts

@@ -0,0 +1,45 @@
+import Constants from "expo-constants";
+
+/**
+ * Turns whatever sits in `drivers.profile_image_url` into something an
+ * `<Image>` can load.
+ *
+ * That column holds one of two things. A driver who took their photo in the
+ * app stores an opaque name ("a1b2….jpg") that only means anything to
+ * /(api)/driver/photo; an owner who filled the field in from the admin
+ * dashboard stores a full external URL. Both have to render, so the shape of
+ * the value decides how it is read — which also means older profiles carrying
+ * a real URL keep working untouched.
+ */
+const ABSOLUTE = /^(https?:|data:|file:|blob:)/i;
+
+/**
+ * The origin an <Image> should fetch from.
+ *
+ * `fetchAPI` gets away with relative paths because expo-router resolves them,
+ * and in development it resolves them against the Metro dev server rather than
+ * the configured origin. An <Image> URL has to be absolute, so it has to make
+ * the same choice by hand — otherwise every API call goes to the laptop while
+ * every avatar goes to production (or, worse, to the placeholder origin in
+ * .env, and silently renders nothing).
+ */
+const apiOrigin = (): string => {
+  if (__DEV__) {
+    const hostUri = Constants.expoConfig?.hostUri;
+    if (hostUri) return `http://${hostUri}`;
+  }
+
+  return (process.env.EXPO_PUBLIC_SERVER_URL ?? "").replace(/\/+$/, "");
+};
+
+export const driverPhotoUri = (value?: string | null): string | undefined => {
+  if (!value) return undefined;
+  if (ABSOLUTE.test(value)) return value;
+
+  const origin = apiOrigin();
+  if (!origin) return undefined;
+
+  // The literal "(api)" is part of the path — this app's routes are addressed
+  // that way throughout, not as an expo-router group that gets stripped.
+  return `${origin}/(api)/driver/photo?name=${encodeURIComponent(value)}`;
+};