Booking and sign-in flow, and the offline build back under guard

Picks up where 0d66627 left off. Three things.

SIGN-IN, CUT TO THE QUESTION IT ASKS
It opened with a quarter-screen crimson hero carrying a lockup, a CUSTOMER
badge, a display-size promise and a sub-line, then a Phone/Email toggle, then a
labelled field, then a card explaining what a verification code is. Six things
to read before the one thing to do.

Nobody arrives at a sign-in screen needing to be sold the product. It is a
heading, a field and a button now, which is where Uber, Bolt and Porter put
them. The toggle became one quiet line under the field — choosing a method was
the first decision on the screen, before the customer had seen what was being
asked, and almost everyone uses the phone. The privacy card went: it explained
that a code would be sent, which the next screen demonstrates a second later.

`DmTextField.label` is nullable for this — "Enter your mobile number" above a
field captioned "Phone number" is one sentence printed twice.

BOOKING, DOWN TO ONE SCREENFUL
Landmark, recipient name and recipient phone are all optional and were all
drawn at the weight of the two fields that are not, putting six rows of "you
may skip this" between the address and the button. They fold behind one row
that counts what is filled in rather than just saying "optional".

Four crimson section heads became one. An accent used five times on a screen is
not an accent; crimson now marks the destination, which is the only choice that
changes the price.

Together those put the window, the package count and the CTA above the fold.

THE OFFLINE BUILD, BACK, UNDER TWO RULES
Deleted on 15 Sep after it cost two rounds of hunting for bookings in the admin
console that had never left the phone. That was not caused by the fake
existing — it was caused by a fake that did not announce itself and that
nothing stopped from shipping. Both are closed:

  * `useDevData` is false in a release whatever the defines say;
  * `describe` leads with DEV DATA (offline) and shows "no network" rather than
    a host the build never contacts.

It is opt-in — `flutter run` still talks to the real API — which is the
property whose absence caused the original mess. `devAutoLogin` is deliberately
false under FLUTTER_TEST so the widget tests keep driving the real entrance.

    flutter run --dart-define=DM_MOCK=true

86 tests green, analyze clean.

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

lib/data/doormile_api.dart

@@ -7,14 +7,24 @@ export 'api_exception.dart';
 
 /// The service surface the app is written against.
 ///
-/// **A shipping build has one implementation: [LiveDoormileApi],** against
-/// `/customer/*` on `api.doormile.com`. When the server cannot be reached the
-/// screens show their designed error state, which is the only honest answer.
+/// **[LiveDoormileApi] is what ships,** against `/customer/*` on
+/// `api.doormile.com`. When the server cannot be reached the screens show their
+/// designed error state, which is the only honest answer.
 ///
-/// The single exception is [DevDoormileApi], reached only when
-/// [AppConfig.useDevData] is set — a `!kReleaseMode` guard, so no define swaps
-/// invented data into a release. It exists because the real backend has no SMS
-/// gateway, so there is otherwise no way to sign in and exercise the flow.
+/// [DevDoormileApi] answers instead when [AppConfig.useDevData] is set — under
+/// `FLUTTER_TEST`, or a debug build given `--dart-define=DM_MOCK=true`. That
+/// getter is `false` in a release whatever is passed, so a shipped build has
+/// one implementation and a booking a customer makes is one the server
+/// accepted.
+///
+/// ── Why this is guarded so tightly ──
+///
+/// An offline build was deleted from this app on 15 Sep 2026 after it cost two
+/// rounds of hunting for bookings in the admin console that had never left the
+/// phone. What made that expensive was not the fake existing — it was that the
+/// fake was reachable without announcing itself, and that nothing stopped it
+/// reaching a release. Both are closed now: the release guard above, and the
+/// Account screen printing DEV DATA (offline) the whole time it is on.
 ///
 /// Screens never see this type at all — they call [AppState], which holds it.
 ///
@@ -25,8 +35,12 @@ abstract class DoormileApi {
 
   static DoormileApi? _instance;
 
-  /// The API this build talks to: the live backend, or [DevDoormileApi] when
-  /// [AppConfig.useDevData] allows it — which is never in a release build.
+  /// The API this build talks to.
+  ///
+  /// [LiveDoormileApi] unless the build asked for offline data, which a
+  /// release build cannot do — see [AppConfig.useDevData]. The check is here
+  /// rather than at the call sites so there is exactly one place that decides,
+  /// and nothing downstream has to know which one it got.
   static DoormileApi get instance =>
       _instance ??= AppConfig.useDevData ? DevDoormileApi() : LiveDoormileApi();