Document v1 domain schema; clarify transaction read and import verify

Move the untracked 'schema draft.sql' to Documentation/schema.sql: the
agreed v1 fuel-domain schema (files, customers, batches, cards,
transactions, invoices, invoice_items), design decisions recorded in the
header: NULL-able cleartext card PINs, slim ledger projection (10 of 16
source fields, the files table is the canonical archive), string customer
business key, unified DECIMAL SEK money, full invoice traceability,
cli.md status values.

cli.md: transaction read takes <date> <receipt> -- the register's
receipt counter repeats across days (9,990 distinct receipts in the
138k-row sample), the day+receipt pair is the ledger dedup key, verified
unique in all samples. File import step 5 clarified as an internal
consistency check, since source files carry no totals of their own.
Invoice business key corrected to invoice number.

readme.md: point the database bullet at Documentation/schema.sql.

Documentation/cli.md

@@ -62,7 +62,11 @@ rpnc
 │   │                #   2. create any missing cards (pin/description nullable)
 │   │                #   3. create transactions
 │   │                #   4. create any missing batches
-│   │                #   5. verify batch values match calculated value
+│   │                #   5. verify batch values match calculated value: the
+│   │                #      file carries no totals of its own, so this is an
+│   │                #      internal check -- recompute each batch touched by
+│   │                #      the import from the transactions table and compare
+│   │                #      with the stored values
 │   │                #   one import is one DB transaction: a step 5 mismatch
 │   │                #   aborts and persists nothing (exit code 1)
 │   ├── list         # list all files stored in DB
@@ -96,7 +100,9 @@ rpnc
 │                    #   optional filters --customer, --from, --to
 │
 └── transaction # immutable; created only via "file import"; no create/update/delete
-    ├── read         # fetch transaction details
+    ├── read         # fetch transaction details by <date> <receipt>:
+                     #   the register's receipt counter repeats across days,
+                     #   so the day + receipt pair is the business key
     └── list         # list transactions
                      #   optional filters --customer, --card, --batch, --from, --to
 ```
@@ -120,8 +126,11 @@ rpnc
 
 ## ID semantics
 Positional `id` arguments take the business key of the entity, never a
-surrogate key: customer number, card number, batch number, invoice id, or
-filename, depending on the entity.
+surrogate key: customer number, card number, batch number, invoice number,
+or filename, depending on the entity. The exception is transactions, whose
+business key is the pair day + receipt (`transaction read <date> <receipt>`):
+the register's receipt counter repeats across days, and the pair is the
+ledger's dedup key (verified unique in all samples).
 
 ## Status values
 - card: active / suspended / cancelled