Redesign on the Stitch reference, in Plus Jakarta Sans

Four passes, and the shape they landed on.

The type face is Plus Jakarta Sans (variable, wght 200-800), which brings a
fix with it: it carries the rupee glyph and Switzer does not, so prices stop
being set in Geist Mono to work around a missing character. Mono stays where
it is earned - references and phone numbers, read digit by digit.

Surfaces lift rather than outline. Cards carry two very soft shadow layers
instead of a hairline, because eight outlined boxes down a screen read as a
wireframe. The tab bar floats as a pill again for the same reason it was
right to: it is now the same kind of object as everything above it.

Screens:

* Home is the greeting, the address, the sphere and one card. The card lost
  its progress bar - a filling line says "wait", and a parcel two days into
  a journey is not something anyone is waiting through - and gained the size
  that buys.
* Orders cards are four bands: identity, destination, route, and whatever is
  happening right now. Plus a search field, because the list is the archive.
* Tracking leads with the state at display size, then TRIP MILESTONES with a
  step counter, then the courier.
* Review is a route thread over two particular cards.
* Account opens on the person: avatar, name, and two counted figures.

Three real bugs the redesign surfaced:

* Quick dispatch handed `loadCities()` straight to a FutureBuilder, so the
  catalogue was refetched on every rebuild and Home never settled.
* Order cards showed the whole visit's weight on one destination's row -
  somebody else's parcel. Per group now, and only once actually weighed.
* The pickup window was printed beside "In transit", where it reads as a
  delivery time nobody promised.

Nothing invented. The reference shows EXPRESS PRIORITY, CARBON OFFSET,
CONCIERGE ELITE and hub-to-hub routing; this backend sends none of them, so
they are absent rather than mocked up.

flutter analyze: clean. flutter test: 88 passing.

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

test/live_api_wire_test.dart

@@ -13,7 +13,7 @@ import 'package:http/testing.dart';
 /// against the customer API document.
 ///
 /// These are not parser tests. Every one of them exists because a plausible,
-/// readable, wrong spelling — `otp` for `code`, `lat` for `latitude`, `min` for
+/// readable, wrong spelling — `otp` for `code`, `latitude` for `lat`, `min` for
 /// `minRupees` — costs a whole feature at runtime and nothing at compile time.
 ///
 /// Where the written contract and the running server disagree, these tests
@@ -96,9 +96,18 @@ void main() {
       ],
     );
 
+    // ── `lat`/`lng`, not `latitude`/`longitude` ──
+    //
+    // The written contract says the long spelling and this app sent it. The
+    // server reads the short one, so it saw a pickup with no coordinates, could
+    // not place it in a serviceable area, and answered every booking with
+    // 422 `unserviceable`. Verified against production on 2026-09-23 one
+    // request apart — same pickup, same slot: long spelling 422, short
+    // spelling 201 and booking DM-252803.
     final pickup = t.sent.body['pickup'] as Map<String, dynamic>;
-    expect(pickup['latitude'], 13.0827);
-    expect(pickup['longitude'], 80.2707);
+    expect(pickup['lat'], 13.0827);
+    expect(pickup['lng'], 80.2707);
+    expect(pickup.containsKey('latitude'), isFalse);
 
     final destination =
         (t.sent.body['destinations'] as List).single as Map<String, dynamic>;
@@ -176,7 +185,7 @@ void main() {
 
     final body = t.sent.body;
     final pickup = body['pickup'] as Map<String, dynamic>;
-    expect(pickup['latitude'], 13.0827);
+    expect(pickup['lat'], 13.0827);
     expect(pickup['contactName'], 'Alex Kumar');
     expect(pickup['contactPhone'], '+919876543210');