feat(v2): lock deposit currency to machine.fiat_code (closes #26)

Each machine handles exactly one currency today (operator-set on
`dca_machines.fiat_code`). The deposit's currency is fully determined
by the machine it's recorded against, so it shouldn't be operator-
chooseable in the first place.

Surfaced during 2026-05-16 E2E testing: Jordan had a "15 USD" deposit
recorded against an EUR Sintra (operator typo in the freeform currency
input). The balance summary is currency-blind (`SUM(amount)` over
mixed currencies), so on the next cash-out the system distributed
15 EUR worth of sats on the strength of that 15 USD row. Worked out
by chance; could have over-paid by ~10% if the actual EUR/USD rate
had been further off.

Fix:
  - `CreateDepositData` / `UpdateDepositData` no longer carry a
    `currency` field. Any client-submitted value is silently dropped
    at Pydantic validation, before reaching the handler.
  - `api_create_deposit` resolves the machine's `fiat_code` and
    passes it to `create_deposit(..., currency=...)` as a required
    keyword arg. The deposit row's `currency` column always matches
    the machine going forward.
  - UI: the freeform `<q-input label="Currency">` becomes a read-only
    `<q-chip>` slot on the amount field, sourced from the new
    `depositMachineFiatCode` computed (resolves via the selected
    client's machine).
  - `m005_lock_deposit_currency_to_machine_fiat_code` migration
    backfills existing rows: every `dca_deposits.currency` gets
    rewritten to match its joined `dca_machines.fiat_code`. Greg's
    stray `15 USD` row becomes `15 EUR` (the right answer at today's
    invariant).

Multi-currency-per-machine support is explicitly out of scope here;
when hardware ships that reads multiple denominations across
currencies, the relevant changes are documented in issue #26's
"Future" section (dca_machines.fiat_codes set, currency-aware
balance summary, etc.). The current fix is "lock the input side";
that future work is "unlock it but constrained to the machine's
declared set".

3 new unit tests (`tests/test_deposit_currency.py`) lock in the
model-contract guarantees. Total suite 89 passing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

migrations.py

@@ -437,3 +437,36 @@ async def m004_introduce_dca_lp_table(db):
         "autoforward_enabled",
     ):
         await db.execute(f"ALTER TABLE satoshimachine.dca_clients DROP COLUMN {col}")
+
+
+async def m005_lock_deposit_currency_to_machine_fiat_code(db):
+    """Rewrite every `dca_deposits.currency` row to match its joined
+    `dca_machines.fiat_code`.
+
+    Today each machine handles exactly one currency (operator-set on
+    `dca_machines.fiat_code`); a deposit's currency is fully determined
+    by the machine it's recorded against. The deposit dialog was
+    historically a freeform text input, which let an operator typo a
+    currency code (e.g., a "15 USD" row landed against an EUR Sintra
+    during 2026-05-16 testing — that mismatch silently inflated the LP's
+    nominal balance because the balance summary is currency-blind).
+
+    `aiolabs/satmachineadmin#26` locks the input side; this migration
+    fixes any rows already on disk. Idempotent: on a fresh install with
+    no mismatches it's a no-op UPDATE.
+    """
+    await db.execute("""
+        UPDATE satoshimachine.dca_deposits AS d
+        SET currency = (
+            SELECT m.fiat_code
+            FROM satoshimachine.dca_machines m
+            WHERE m.id = d.machine_id
+        )
+        WHERE EXISTS (
+            SELECT 1
+            FROM satoshimachine.dca_machines m
+            WHERE m.id = d.machine_id
+              AND m.fiat_code IS NOT NULL
+              AND m.fiat_code != d.currency
+        )
+        """)