feat: re-model drawer cash as directional vouchers (Mandat Arkëtimi / Pagese)

Replace the single signed-± cash_movement with two distinct financial
documents — the direction is the event TYPE, not the sign of an amount:

  cash_in  = Mandat Arkëtimi (receipt / pay-IN,  +)  voucher AR-NNNN
  cash_out = Mandat Pagese  (disbursement / pay-OUT, −)  voucher PA-NNNN

Each carries a positive magnitude, voucher number, reason, the operator who
raised it and the admin who authorized it, and prints an Albanian slip.

Authorization changes from admin-only to operator-RAISED / admin-AUTHORIZED:
any shift:create holder raises the voucher, but POST /api/cash-voucher only
commits when authorizedBy is a real admin (shift:cash) re-entering their
password (verified server-side). Keeps the float control while letting the
operator do the booth paperwork.

Legacy cash_movement events are kept — they still verify and still fold into
the drawer (signed-±); the append-only chain is never rewritten. The drawer
fold and the Z-report window now sum all three types.

Verified against a copy of the live DB with the real signing modules:
cash_in 3000 + cash_out 5000 → drawer −2000, hash-chain verifies OK.

Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V

wiki/concepts/shift.md

@@ -121,20 +121,37 @@ The Z-report's payment totals answer "how much did this shift *take*?" — but a
 **physical cash drawer** that carries across shifts. The drawer is tracked as a running balance over
 the signed chain, so each shift knows what it **inherited** and what it should **hand over**.
 
-**The events:**
-- A new signed **`cash_movement`** event: the admin loads or removes drawer cash, `{ amountMinor
-  (signed: + load, − removal), reason, operator }`. **Admin-only** (an operator takes payments but
-  cannot move the float in/out). The opening-day load (+5000 ALL) and a mid-shift withdrawal (−5000)
-  are both `cash_movement` events.
+**The events (drawer vouchers — re-modelled 2026-06-20):** the original design used one signed
+**`cash_movement`** event with a *signed* `amountMinor` (+ load / − removal). That conflated two
+distinct financial documents into a `±`. In accounting a pay-in and a pay-out are different vouchers
+(in Albanian: **Mandat Arkëtimi** = receipt, **Mandat Pagese** = disbursement), so the direction now
+lives in the **event type**, not the sign of an amount:
+
+- **`cash_in`** (*Mandat Arkëtimi* — a **receipt / pay-IN**): cash enters the drawer. `amountMinor` is
+  a **positive magnitude**. Voucher no. `AR-NNNN`.
+- **`cash_out`** (*Mandat Pagese* — a **disbursement / pay-OUT**): cash leaves the drawer.
+  `amountMinor` positive; the fold subtracts it. Voucher no. `PA-NNNN`.
+- Payload: `{ amountMinor (positive), reason, currency, operator (who raised), authorizedBy (admin who
+  signed off), voucherNo }`. Each prints a **slip** (Albanian, like every operator-facing paper).
+- **Authorization changed: operator-RAISED, admin-AUTHORIZED.** Previously admin-only. Now any holder
+  of `shift:create` (operator-grade) may *raise* a voucher, but the route only commits it if
+  `authorizedBy` is a real **admin** (`shift:cash`) who **re-enters their password**. This keeps the
+  float control — an operator can't move the float alone — while letting them do the paperwork at the
+  booth. (`POST /api/cash-voucher`, guarded `shift:create` + server-side authorizer password+grade check.)
+- **Legacy `cash_movement` stays valid.** The type is retained; historical signed events on the live
+  chain still verify and still fold into the drawer (signed-± as before). Only *new* movements use the
+  voucher pair. The append-only chain is never rewritten.
 - The existing `payment` events already add cash to the drawer (cash tender only; card never touches
   the drawer).
 
-**The math — drawer is a fold over the chain BY TIME, not by operator** (a `cash_movement` is the
-admin's, not the shift operator's, so it can't key off `identity`):
+**The math — drawer is a fold over the chain BY TIME, not by operator** (a drawer voucher is the
+admin's authorization, not the shift operator's takings, so it can't key off `identity`):
 
 ```
-expectedDrawer(at) = Σ cash payments (tender=cash) up to `at`
-                   + Σ cash_movement amounts up to `at`
+expectedDrawer(at) = Σ cash payments (tender=cash)        up to `at`
+                   + Σ cash_in amounts (positive)         up to `at`
+                   − Σ cash_out amounts (positive)        up to `at`
+                   + Σ cash_movement amounts (legacy, signed) up to `at`
 ```
 
 A shift's **opening float = expectedDrawer(shiftStart)** — i.e. everything that happened to the drawer
@@ -150,11 +167,11 @@ That `expectedDrawer` is exactly the **next** shift's opening float — the carr
 
 | Step | Event | Drawer |
 | --- | --- | --- |
-| Opening day | admin `cash_movement` +5000 | 5000 |
+| Opening day | `cash_in` (Mandat Arkëtimi) +5000 | 5000 |
 | Shift 1 takes 6500 cash | payments | 11500 |
 | Shift 1 closes | Z: open 5000, took 6500, expected **11500** | 11500 |
 | Shift 2 opens | opening float = **11500** (inherited) | 11500 |
-| admin `cash_movement` −5000 | withdrawal | 6500 |
+| `cash_out` (Mandat Pagese) 5000 | withdrawal | 6500 |
 | Shift 2 takes 4500 cash | payments | 11000 |
 | Shift 2 closes | Z: open 11500, took 4500, removed 5000, expected **11000** | 11000 |
 | Shift 3 opens | opening float = **11000** | … |
@@ -179,13 +196,19 @@ reconciles the signed Z-report against the actual drawer and the bank/POS batch
 
 ## Open
 
-- **Drawer carry-over (decided 2026-06-18, building):** opening float auto-inherits the prior shift's
-  expected drawer; admin-only `cash_movement` events; Z-report reports the full drawer picture. See
-  the Drawer balance section above.
+- **Drawer carry-over (decided 2026-06-18, built; vouchers re-modelled 2026-06-20):** opening float
+  auto-inherits the prior shift's expected drawer; drawer movements are now the **`cash_in` /
+  `cash_out` voucher pair** (Mandat Arkëtimi / Mandat Pagese — direction is the type, operator-raised
+  & admin-authorized), superseding the signed-± `cash_movement` (kept for history). Z-report reports
+  the full drawer picture. See the Drawer balance section above.
 - **Shift ↔ session boundary:** a vehicle may enter under one shift and pay under another — the
   Z-report sums by **payment time** (when cash/card was taken), which is the operator who handled
   the money. Confirm that's the intended accountability (vs. by entry).
-- **Mid-shift report / X-report** (read-only "so far" total without closing) — add if booths want
-  it; the sum is the same projection.
+- **Mid-shift report / X-report — REQUESTED 2026-06-20, not yet built.** The operator wants to see,
+  on demand during the shift, the **opening float inherited**, **cash collected so far**, the
+  pay-ins/pay-outs, and the **current expected drawer balance** — without closing. It's the same
+  drawer projection the Z-report computes, just read-only and mid-shift. (The header already shows the
+  live drawer *total*; this is the full breakdown.) Deferred behind the voucher re-model done the same
+  day; build next if wanted.
 - **Multiple lanes/booths** — whether a shift is per-operator, per-booth, or per-site
   (relates to [[open-questions]] #1 lane topology).