Miler rider app: surface system, visible design language, backend lifecycle

Design system
- MilerSurface ladder (canvas → working → raised → floating) with MilerPanel
  as layer 1; canvas moved to #DEE3EA so white separates at 1.290:1.
- Visible vocabulary applied across Home, Deliveries, Activity, Account and
  the sheets: hero heads (tabular numeral + small caption, clamped at 1.3x),
  canvas wells for anything that opens, small filled tags for shelf labels,
  demoted placeholders. Recorded in DESIGN_SYSTEM.md §6.
- One icon family: 222 Material glyphs migrated to Lucide; none left outside
  lib/xpress.
- Colour semantics corrected: amber only for what is genuinely owed, brand red
  reserved for the live stop, disabled primaries go neutral rather than pale.

Data and lifecycle
- lib/data/lifecycle.dart reads mutations for what they prove; route_order.dart
  makes admin sequence the single ordering authority; service_day.dart, and
  stop_area.dart rewritten against live Coimbatore addresses (digit-token
  stripping, city stoplist, street suffixes, stammer collapse).
- countLabel states the load once, in bags.

Testing
- 1440 tests passing; golden shot harnesses for Home, Deliveries, Activity,
  sheets and verify, with test/failures/ now gitignored (diff debris).
- New pins: home_gutter_test, stop_area_test, plus updated structural bounds.

Note: this commit also carries pre-existing working-tree deletions that were
present before this work (API_SPEC.md, README.md, demo test fixtures).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

lib/helpers/app_bootstrap.dart

@@ -8,7 +8,7 @@ import 'package:miler/controllers/auth.dart';
 import 'package:miler/views/introscreens/introscreen.dart';
 import 'package:miler/views/onboardscreens/Mpin.dart';
 import 'package:miler/views/onboardscreens/Sign_in.dart';
-import 'package:miler/widget/Bottom_page.dart';
+import 'package:miler/helpers/rider_shell.dart';
 
 /// Decides which screen the app opens on, and nothing else.
 ///
@@ -109,7 +109,11 @@ class _AppBootstrapState extends State<AppBootstrap> {
     // pass a slider that put him back on the clock. Duty is a switch in Home's
     // app bar, on the screen where the work is.
     if (!isLoggedOut && savedUserId != null && savedUserId > 0) {
-      Get.offAll(() => const BottomPage());
+      // Which of the two dashboards this rider works in — parcel or the ported
+      // delivery flow — decided by his tenant. `main()` awaits
+      // `TenantController.load()` before the first frame, so the answer is
+      // already on hand here. See [riderShell].
+      Get.offAll(() => riderShell());
     } else {
       Get.offAll(() => hasSeenIntro ? const SignIn() : Introscreen());
     }

lib/helpers/rider_shell.dart

@@ -0,0 +1,88 @@
+import 'package:flutter/material.dart';
+
+import 'package:miler/data/service_profile.dart';
+import 'package:miler/widget/Bottom_page.dart' as parcel;
+import 'package:miler/xpress/delivery_bootstrap.dart';
+import 'package:miler/xpress/widget/Bottom_page.dart' as delivery;
+
+/// ─────────────────────────────────────────────────────────────────────────
+/// WHICH APP THIS RIDER GETS
+///
+/// One APK, two applications. A rider signs in and lands in whichever of them
+/// his tenant says he works for:
+///
+///  • **parcel / meals** → the Miler dashboard: floating frosted tab bar, Home ·
+///    Bookings · Activity · Account, the pickup flow with its stop verification
+///    and cash collection.
+///
+///  • **delivery** → the ported Xpress-rider dashboard under `lib/xpress`:
+///    classic bottom bar, HOME · DELIVERIES · SUMMARY · PROFILE, the last-mile
+///    delivery flow, in Doormile red.
+///
+/// ── Why the switch is here and not inside the shell ──
+///
+/// The obvious alternative is one `BottomPage` that picks its own tabs. It does
+/// not work: the two shells disagree about how many tabs there are, what a tab
+/// is called, how the bar is drawn, and — the part that actually decides it —
+/// which page widgets exist. The delivery pages are a verbatim port that reads
+/// its own controllers, its own models and its own colour class. Fusing the two
+/// shells would mean editing the ported flow, which is the one thing the port
+/// was meant to avoid.
+///
+/// So the shells stay whole and separate, and exactly one function chooses
+/// between them.
+///
+/// ── Why it is a function and not a route ──
+///
+/// Every caller already says `Get.offAll(() => const BottomPage())`. Making this
+/// a widget-returning function means those sites become
+/// `Get.offAll(() => riderShell())` and nothing else about routing changes —
+/// no named routes, no redirect middleware, no second navigator.
+///
+/// ── When it is safe to call ──
+///
+/// After `TenantController.load()` has run, which `main()` awaits before the
+/// first frame. [ServiceProfile.active] is a plain synchronous read, so this
+/// needs no context, no await and no rebuild.
+///
+/// ── The fallback ──
+///
+/// Anything that is not explicitly the delivery line gets the parcel shell,
+/// matching the direction [resolveServiceProfile] already falls in. The worst
+/// case that way is a delivery rider seeing the parcel dashboard, which is
+/// wrong but navigable; the other direction would drop a live parcel rider into
+/// an app with no pickup flow at all.
+/// ─────────────────────────────────────────────────────────────────────────
+Widget riderShell({int initialIndex = 0, Widget? overridePage}) {
+  if (ServiceProfile.active.isDelivery) {
+    // ── Why this is here and not only in `main()` ──
+    //
+    // `main()` boots the delivery line's controllers when the app *starts* on a
+    // delivery tenant. But a rider can also arrive here without a restart: sign
+    // out of a parcel account, sign in to a delivery one, and `Mpin` routes
+    // straight to this function inside a process whose container only ever held
+    // the parcel controllers.
+    //
+    // The delivery home page resolves `DeliveryController` in a field
+    // initialiser, so that path would throw while building rather than degrade.
+    // [registerDeliveryLine] is `isRegistered`-guarded, so calling it on every
+    // shell build costs four map lookups and closes the hole.
+    //
+    // Deliberately the **synchronous** half of the bootstrap, not the `async`
+    // one. An un-awaited async registration returns at its first `await`, the
+    // framework builds this shell in the gap, and the page throws on a
+    // controller that is about to exist — see the note on [registerDeliveryLine].
+    // The IO half is `main()`'s to await; nothing on screen needs it to have
+    // finished, because the screens re-read that state anyway.
+    registerDeliveryLine();
+
+    return delivery.BottomPage(
+      initialIndex: initialIndex,
+      overridePage: overridePage,
+    );
+  }
+  return parcel.BottomPage(
+    initialIndex: initialIndex,
+    overridePage: overridePage,
+  );
+}