Give every terminal its own identity, and report fleet presence

Answers "which of my 100 tills are alive and healthy", and fixes three things
that were fine on one device and broken on a hundred.

Terminal identity (lib/data/local/terminal_identity.dart)
- Every device mints a UUID on first run, stored in its own database, plus a
  short code (T4A9) derived from it. Renaming keeps the device id, so history
  keeps pointing at the same physical till.
- Replaces the literal 'TERM-01', which was hardcoded in five places. The whole
  fleet reported as one terminal: shift reports merged, MQTT topics collided,
  and a second connection with the same client id evicts the first from the
  broker — so two tills would have knocked each other offline in a loop.

Invoice numbers now carry the terminal code
- INV-2608-T4A9-00042. The sequence counter lives in each till's own database
  and starts at 1, so without this every terminal in the fleet minted
  INV-2608-00001 for its first sale of the month. The order UUID kept the data
  distinct; the number a customer quotes on a receipt was not.

SQLite pragmas
- WAL, so the product grid refreshing does not block the sale being written,
  and the file is never left mid-rewrite by a power cut.
- busy_timeout 5s, so a contended lock waits instead of throwing "database is
  locked" — which at checkout is a failed sale with a customer standing there.
- synchronous NORMAL, the right trade under WAL for a till.

Fleet presence (lib/data/sync/presence_reporter.dart)
- Retained status record on connect and once a minute: device id, code, name,
  app version, pending bill count, last upload, catalogue revision, sync halt
  state. Retained so a dashboard connecting at noon gets all 100 terminals
  immediately rather than a blank board.
- The Last Will already said "reachable". A till can be connected and still be
  holding 200 unsent bills or running last month's prices; only pending_bills
  and catalogue_revision say so.

NATS
- The MQTT gateway maps / to . so the existing transport works unchanged.
  SyncConfig.asNatsSubject() exposes the translation, and the contract doc
  gives the JetStream subjects (pos.*.*.order, pos.*.*.status) plus the two
  server-side requirements: a file-backed stream, and the ack published by the
  consumer after commit rather than by the ingest handler.

Tests: 129 -> 140. New coverage for identity minting and stability, per-device
invoice uniqueness, topic and client-id separation, NATS subject mapping, and
the two pragmas. Suite run three times clean.

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

docs/sync-contract.md

@@ -47,6 +47,11 @@ Every `order.id` is a UUID minted at the till. Put a unique index on it and
 upsert. Without this you will double-count a day's takings the first time a
 shop's line wobbles.
 
+Invoice numbers are `INV-2608-T4A9-00042` — the terminal code is in there
+because each till's sequence counter lives in its own database and starts at 1.
+Unique per terminal, not globally sequential. Do not assume gaps mean missing
+bills; a till that was replaced restarts its own series.
+
 **4. A refusal is final, a failure is not.**
 Naming an id in `rejected` halts the terminal's drain — it will not retry the
 same bytes, and a person has to press Sync. Use it for "this bill is wrong"
@@ -63,11 +68,62 @@ connection or return 5xx instead, and the terminal will back off and retry.
 | `pos/{store}/{terminal}/command` | cloud → till | 1 | no |
 | `pos/{store}/catalogue` | cloud → all tills | 1 | **yes** |
 
+`{store}` and `{terminal}` come from the device's own identity, minted on first
+run and stored in its database. They are never literals — 100 tills sharing one
+id would collide on every topic and evict each other from the broker, since a
+second connection with the same client id kicks the first off.
+
 `status` is also the Last Will. If a till loses power the broker publishes
 `{"state":"offline"}` on its behalf — that is what makes a "which tills are
 dark" board possible, and it is the only way to tell *closed for the night*
 from *unplugged*.
 
+### Running this on NATS
+
+The MQTT gateway maps `/` to `.`, so the topics above arrive as subjects and a
+JetStream consumer binds to them directly:
+
+| Purpose | Subject |
+|---|---|
+| Every till's bills | `pos.*.*.order` |
+| Every till's presence | `pos.*.*.status` |
+| One store's bills | `pos.store-01.*.order` |
+| Ack back to one till | `pos.store-01.T4A9.ack` |
+
+`SyncConfig.asNatsSubject()` does the translation, so a consumer's subject can
+be read off the terminal rather than guessed.
+
+Two things to get right on the NATS side:
+
+- **The stream must be durable and file-backed.** A memory stream loses a shop's
+  bills on a server restart, and the till has already been told they landed.
+- **Publish the ack from the consumer, after the database commit** — not from an
+  ingest handler that has merely queued the work. The ack is the terminal's
+  only evidence, and it deletes its copy seven days later on the strength of it.
+
+### Fleet presence
+
+Every terminal publishes a retained record on its status topic on connect and
+once a minute. Retained matters: a dashboard connecting at noon gets all 100
+terminals' last state immediately instead of a blank board.
+
+```json
+{
+  "schema": 1, "state": "online",
+  "device_id": "…", "terminal_code": "T4A9", "terminal_name": "Counter 2",
+  "store_id": "store-01", "app_version": "1.1.0",
+  "reported_at": "2026-08-01T14:22:05Z",
+  "pending_bills": 3, "last_upload_at": "…", "catalogue_revision": "rev-8821",
+  "sync_halted": false, "sync_error": null, "consecutive_failures": 0,
+  "transport": "mqtt"
+}
+```
+
+The Last Will answers *is it reachable*. These fields answer *is it healthy* —
+a till can be connected and still be holding 200 unsent bills or running last
+month's price list, and only `pending_bills` and `catalogue_revision` will say
+so.
+
 ## Payloads
 
 **Uplink** — `pos/{store}/{terminal}/order`
@@ -77,7 +133,7 @@ from *unplugged*.
   "schema": 1,
   "batch_id": "9f1c…",
   "store_id": "store-01",
-  "terminal_id": "TERM-01",
+  "terminal_id": "T4A9",
   "sent_at": "2026-08-01T14:22:05.123Z",
   "orders": [ { "id": "…", "invoice_number": "…", "items": [ … ] } ]
 }