Drain bills to the back office automatically, over MQTT or HTTP

Turns the orders table into a queue that empties itself. Bills were only
uploaded when a cashier pressed Sync at end of day; a till that was never
pressed held a day's takings indefinitely.

Drain engine (lib/data/sync/sync_engine.dart)
- Triggers on sale committed, network regained, 5-minute poll, head-office
  request, and the manual button.
- Single flight: a busy till firing a trigger per sale would otherwise have
  several passes reading the same pending rows and send every bill twice.
  A trigger arriving mid-drain is queued and replayed, so nothing is dropped.
- Exponential backoff with +/-20% jitter to a 5-minute ceiling. The jitter
  matters: a store's terminals all fail at the same instant when the line
  drops, and would retry in lockstep without it.
- Halts rather than loops on a failure retrying cannot fix (bad credential,
  refused batch). Pressing Sync clears the halt.

Transports (lib/data/remote/)
- OrderTransport interface; MQTT, HTTP and simulated implementations. The
  repository does not know which is in use.
- MQTT: QoS 1 uplink, application-level ACK correlated by batch_id on a return
  topic, retained Last Will for terminal-offline detection, downlink for
  catalogue pushes and remote sync requests.
- A broker PUBACK is never treated as acceptance. It means the broker holds
  the bytes, not that the ledger took the sale. Only ids the back office names
  are marked synced; silence leaves a bill pending.
- HTTP carries a stable idempotency key across retries of the same bills.

Retention
- Accepted bills are kept 7 days instead of deleted, so a batch the back
  office later loses can be re-sent in full. Purged after that; archived
  totals stay forever.
- forBusinessDate now reads pending rows only. A retained bill exists in both
  the orders table and day_archive, and summing both would overstate the day.

Fixes found while building this
- SyncEngine._refreshPending wrote state.copyWith(pending: await ...). Dart
  evaluates the receiver before the awaited argument, so a connectivity drop
  during the wait was silently overwritten by the stale snapshot. Caught by
  the first run of the new engine tests.
- PrinterSettingsController wrote state after four awaits with no mounted
  check, throwing "used after dispose" when Settings was left mid-load. This
  was pre-existing and reached the cashier as a red screen.

Also
- Header pill now reports real sync state: LIVE / n QUEUED / SYNCING /
  SYNC HALTED, with an explanation of where the bills are.
- Settings shows the route, last upload, next retry and retention window.
- docs/sync-contract.md states what the back office must implement, including
  the idempotency requirement that at-least-once delivery makes mandatory.

Tests: 90 -> 129 passing. New coverage for backoff shape and jitter band,
single flight, halting, ACK correlation and partial acceptance, at-least-once
duplicate handling, retention and purge, and no double-counting after a sync.
Suite run six times clean.

Not addressed: bills already synced by an older build went up overstated and
still need server-side reconciliation. Broker credentials have no Settings
editor yet.

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

lib/presentation/sync/providers/sync_controller.dart

@@ -167,6 +167,12 @@ class OrderSyncController extends StateNotifier<OrderSyncState> {
   bool get isRunning => state is SyncRunning;
 
   /// Uploads every bill at sync_status = 0 and flips the accepted ones to 1.
+  ///
+  /// Goes through the engine rather than straight to the repository, so a
+  /// cashier pressing sync while a background drain is already mid-flight
+  /// joins it instead of starting a second pass over the same rows. It also
+  /// clears a halt: pressing the button is how you retry after the back office
+  /// has been fixed.
   Future<SyncOutcome> run() async {
     if (isRunning) {
       return const SyncOutcome(attempted: 0, uploaded: 0);
@@ -174,7 +180,7 @@ class OrderSyncController extends StateNotifier<OrderSyncState> {
 
     state = const SyncRunning(0, 'Starting…');
 
-    final outcome = await _ref.read(syncRepositoryProvider).syncOrders(
+    final outcome = await _ref.read(syncEngineProvider).syncNow(
           onProgress: (progress, stage) {
             if (mounted) state = SyncRunning(progress, stage);
           },
@@ -192,3 +198,30 @@ final orderSyncProvider =
     StateNotifierProvider<OrderSyncController, OrderSyncState>(
   (ref) => OrderSyncController(ref),
 );
+
+// ------------------------------------------------------- Background drain
+/// Brings the queue-and-drain machinery up, once, when the shell mounts.
+///
+/// Deliberately not gated on sign-in: a terminal that boots holding yesterday's
+/// bills should be emptying its queue before anyone reaches the till.
+///
+/// Overridden to a no-op in widget tests, which have no network stack and
+/// cannot drive real disk I/O on a fake clock.
+final syncBootstrapProvider = FutureProvider<void>((ref) async {
+  await ref.read(connectivityServiceProvider).start();
+
+  final engine = ref.read(syncEngineProvider);
+
+  // A background drain moves bills out of the pending set, so the tallies and
+  // shift totals on screen are stale the moment one finishes.
+  var wasSyncing = false;
+  final subscription = engine.states.listen((state) {
+    if (wasSyncing && !state.isSyncing) {
+      ref.read(orderVersionProvider.notifier).state++;
+    }
+    wasSyncing = state.isSyncing;
+  });
+  ref.onDispose(subscription.cancel);
+
+  await engine.start();
+});