Pull the catalogue from a real endpoint, with delta sync

Replaces the last simulation on the inbound side. RemoteCatalogueSource
returned SeedData after a fake progress bar; there was no wire format, no
endpoint, and no way to receive an update short of reinstalling.

Wire format (data/remote/catalogue_wire.dart)
- Tolerant where it should be: a catalogue of 4,000 products must not fail to
  import over one absent emoji, so optional fields take defaults and an
  unrecognised category files under Grocery — the item still scans, prices and
  bills.
- Strict where it matters: no id, name, barcode or price and the import fails.
  A silently dropped product is a shelf item that scans to nothing, discovered
  with a queue waiting.
- GST accepts 18 or 0.18 and reads both the same. Back offices disagree about
  which they mean, and getting it wrong silently changes the tax on every line.

HTTP source with paging and deltas
- GET {base}/catalogue?since={revision}&page={n}. Paged because a supermarket
  catalogue is tens of thousands of rows: one response times out on a shop's
  line and stalls the UI decoding it. Capped at 200 pages so a bad deployment
  cannot become an infinite request loop against a shop's connection.
- `since` carries the revision already held, so a normal morning fetches a
  handful of price changes rather than the whole book. A server that cannot do
  deltas ignores it and answers is_delta:false — the terminal reads the flag
  rather than assuming, so both work.
- A bad credential is non-retryable and says so, leaving the working catalogue
  in place so billing continues.

Applying deltas without losing local state
- A full snapshot withdraws what it omits; a delta must not. Read as a
  snapshot, the first morning price change would empty the shelf.
- Retired products are marked inactive, not deleted — order lines already
  recorded point at them, and a hard delete would orphan a bill's history.
- Locally registered shoppers survive a pull, as before.
- The unsynced-stock replay is now scoped to the products the pull actually
  overwrote. It exists because a server count predates local sales; running it
  over a delta that never carried that product would subtract those units a
  second time and quietly empty a shelf that is full. Both halves of that rule
  are tested.

MQTT stays the nudge, not the transport: a catalogue push on
pos/{store}/catalogue makes every terminal pull immediately, but the rows come
over HTTP, because a broker is the wrong shape for tens of thousands of them.

Tests: 210 -> 234. docs/sync-contract.md now covers both directions, including
a field-by-field table of what happens when something is missing.

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

docs/sync-contract.md

@@ -157,6 +157,70 @@ nothing is marked synced, and the batch goes again.
 response. Carries an `idempotency-key` header that is stable across retries of
 the same bills.
 
+## Catalogue pull
+
+The other direction: products and customers coming down.
+
+```
+GET {base}/catalogue?since={revision}&page={n}&store_id=…&terminal_id=…
+Authorization: Bearer {apiKey}
+```
+
+```json
+{
+  "revision": "rev-8821",
+  "is_delta": true,
+  "has_more": false,
+  "products":  [ { "id": "…", "name": "…", "barcode": "…", "price": 62.0, … } ],
+  "customers": [ { "id": "…", "name": "…", "mobile": "…", … } ],
+  "retired_product_ids": ["sku-9912"]
+}
+```
+
+**Paged.** A supermarket catalogue is tens of thousands of rows; one response
+times out on a shop's line and stalls the UI while it decodes. Answer
+`has_more: true` and the terminal asks for the next page, up to 200 — past that
+it stops rather than looping against the shop's connection.
+
+**`since` is the revision the terminal already holds.** Answer with what has
+moved and set `is_delta: true`. On a normal morning that is a handful of price
+changes rather than the whole book. A server that cannot do deltas ignores the
+parameter and answers `is_delta: false`; the terminal reads the flag rather
+than assuming, so both work.
+
+**The flag matters more than it looks.** A full snapshot withdraws every product
+it does not mention. A delta must not — read as a snapshot, the first morning
+price change would empty the shelf. Withdraw items in a delta with
+`retired_product_ids`; the terminal marks them inactive rather than deleting,
+because order lines already recorded point at them.
+
+**Send stock only when you mean it.** Any product in the payload has its count
+overwritten by the server's figure, which predates sales this terminal has rung
+but not yet uploaded. The terminal replays those sales — but only for products
+the payload actually carried. A delta that ships a stale count for an untouched
+product will quietly empty a shelf that is full.
+
+### Field handling
+
+| Field | Missing | Notes |
+|---|---|---|
+| `id`, `name`, `barcode`, `price` | **import fails** | A dropped product is a shelf item that scans to nothing |
+| `sku` | falls back to `id` | |
+| `stock` | `0` | Means "not tracked" |
+| `gst_rate` | 18% | Accepts `18` or `0.18` — both read the same |
+| `category` | Grocery | An unrecognised one also falls back; the item still sells |
+| `unit` | piece | Matched by name or symbol |
+| `is_active` | `true` | An omitted flag is not a withdrawn catalogue |
+
+Dates are ISO 8601 or epoch milliseconds; both are accepted.
+
+### Pushing a change mid-day
+
+Publish to `pos/{store}/catalogue` (retained) and every terminal in the shop
+pulls immediately instead of waiting for tomorrow morning. The message body is
+only a nudge — the catalogue itself still comes over HTTP, because a broker is
+the wrong shape for tens of thousands of rows.
+
 ## Retention on the terminal
 
 Accepted bills stay for 7 days (`OrderDao.retentionWindow`) so a batch the
@@ -181,3 +245,7 @@ overstate the day.
 - **Historical correction.** Bills already synced by an older build went up
   with an overstated total. Nothing here fixes that; it needs a server-side
   reconciliation against `bill_discount`.
+- **Pushing customers upward.** A shopper registered at the till stays on that
+  terminal and rides along on the bills they appear on. There is no
+  customer-create endpoint yet, so two terminals registering the same mobile
+  number will each hold their own row until the back office reconciles them.