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

README.md

@@ -199,6 +199,56 @@ you the Account screen — which is exactly when you need to know.
 and it refused the code. `1234` is not a real code; only the offline build
 accepts anything. See below.
 
+### Two contract bugs found against production, 2026-09-23
+
+Both were the same mistake — the client spelling a field the way the written
+contract spells it, where the server reads something else — and both were
+verified one request apart against `api.doormile.com`, same pickup, same slot.
+
+**The pickup coordinates are `lat`/`lng`, not `latitude`/`longitude`.**
+
+| sent | `POST /bookings` |
+| --- | --- |
+| `latitude` / `longitude` | **422 `unserviceable`** — "We are not collecting from that area yet" |
+| `lat` / `lng` | **201**, booking `DM-252803` |
+
+The server could not read the pin, could not place it in a serviceable area,
+and blamed the customer's address for a field name. **The app could not create
+a booking at all**; every serviceable district's own hub coordinates were
+refused as a pickup. Fixed in `Place.toJson`.
+
+**The same bug in `POST /fare/estimate` returns a wrong price instead of an
+error**, which is worse:
+
+| sent | local (0.2 km) | Chennai (427 km) |
+| --- | --- | --- |
+| `latitude` / `longitude` | ₹280–520, `routeKm` 0 | ₹280–520, `routeKm` 0 |
+| `lat` / `lng` | ₹45–90 | ₹150–280 |
+
+With the long spelling the server measures no route and answers a flat fallback
+band for every journey — roughly six times the real price on a local run, and
+the same number quoted for a parcel crossing the state. Every fare this app has
+shown was that fallback. Fixed in `LiveDoormileApi.estimateFare`.
+
+This is the third of these (`POST /auth/otp/verify` takes `code` where the
+document says `otp`). **Follow the server, not the document**, and
+`test/live_api_wire_test.dart` is where each one gets pinned down.
+
+### The app cannot sign in to production
+
+Separate from the above, and still open. The real backend has no SMS gateway,
+so the OTP never arrives. The server does have a PIN flow —
+
+```
+POST /customer/auth/login       {"phone": "+91…"}   → {registered, pin_set}
+POST /customer/auth/verify-pin  {"phone", "pin"}    → {accessToken, refreshToken, customer}
+```
+
+— but the app does not use it: `login_screen.dart` calls `sendOtp`. Until those
+two endpoints are wired into the entrance, a booking cannot be made **from the
+app** against production, whatever the payload says. The QA account
+`+919999900001` ("Doormile QA") is registered with a PIN for exactly this.
+
 ### Signing in for development
 
 A shipping build has **one** API implementation, `LiveDoormileApi`, and it talks