feat(desktop): Tauri v2 kiosk shell — maximized window, prod right-click block, auto-update + code-signing

Add apps/desktop, a thin Tauri v2 shell wrapping the SAME @parking/web SPA so
the desktop and browser UIs never drift: dev loads the Vite dev server (HMR),
prod bundles the web app's dist/. No business logic in the shell (device/auth/
ledger stay in @parking/server); deny-by-default capabilities.

apps/web (single UI source of truth):
- lib/origin.ts: centralize the backend origin (API_BASE/apiUrl/wsUrl from
  VITE_API_BASE); no-op in the browser, lets the desktop build target Fastify.
- lib/kiosk.ts: block the right-click context menu in PROD only (dev keeps it +
  devtools).
- lib/desktop-updater.ts: prompt-on-update auto-update (no-op in browser/offline)
  → downloadAndInstall + relaunch; i18n update.* keys (sq+en).
- .env.production: VITE_API_BASE wired to the Fastify origin for the bundle.

Desktop:
- window starts maximized (not fullscreen — operator keeps OS access).
- auto-update via tauri-plugin-updater + -process; self-hosted endpoint is a
  PLACEHOLDER to fill in. Updater keypair: pubkey embedded in tauri.conf.json;
  private key + password kept OUTSIDE the repo (~/.parking-updater-keys) and as
  TAURI_SIGNING_* build secrets.
- Turbo build is a no-op; the real signed bundle is `pnpm --filter
  @parking/desktop bundle` (verified → .deb/.rpm/.AppImage + .sig signatures).

Verified: cargo check clean; turbo run build lint 14/14 green; i18n parity holds;
no key/sig/bundle artifacts in the repo.

Wiki (security + desktop analysis recorded alongside):
- new concepts/tpm.md (TPM 2.0: how it works, sealed-LUKS auto-unlock + non-
  extractable signing key, limits — live-root, bus-sniff — TPM-vs-ATECC608 by
  platform).
- new decisions/desktop-shell-tauri.md (Tauri v2 over Electron; best-case Ubuntu
  26.04 LTS, worst-case Windows+WSL → kiosk browser; full as-built).
- pull-the-disk attack trace on append-only-event-chain; ATECC608 not-in-a-PC
  caveat; cross-links from disk-os-hardening / threat-model.
- open-questions #11 (appliance WebKitGTK), #12 (TPM hardening impl), #13
  (startup verifyChain self-check); index/overview/log/standing-decisions.

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

wiki/concepts/append-only-event-chain.md

@@ -69,10 +69,21 @@ secure element is a new `Signer` impl with no `EventLog` change; each event stor
 so old events stay verifiable.
 
 > ⚠️ The software signer makes the chain **self-consistent + tamper-evident**, but **not
-> unforgeable by someone who owns the host** — only the ATECC608's non-extractable key gives
-> property (3) above. Until the chip is wired, the chain detects tampering by *outsiders* and
-> *accidental* corruption, but an operator with the signing key + DB access could re-sign a
-> forged chain. This is the central reason #6 matters.
+> unforgeable by someone who owns the host** — only a non-extractable key in a secure element
+> ([[atecc608]] on embedded, or the host **[[tpm|TPM]]** on a PC appliance) gives property (3) above.
+> Until that is wired, the chain detects tampering by *outsiders* and *accidental* corruption, but an
+> operator (or anyone who pulls the SSD and reads the `.env`) has the HMAC key and could **edit a row
+> and re-sign the whole chain undetectably**. This is the central reason #6 matters.
+
+> **Pull-the-disk attack (traced 2026-06-21).** Removing the SSD, editing `parking.sqlite` on
+> another machine, and rebooting: any blind edit/delete/reorder **breaks the chain** and
+> `verifyChain()` pinpoints it (bad signature / index gap / prevHash mismatch / unknown keyId). **But
+> two gaps:** (a) **nothing runs `verifyChain()` at startup today** — the tamper is *detectable but
+> undetected* until something invokes verification (wire a boot-time self-check that at least logs/flags
+> a signed alarm — fail-open on exit still governs; this is [[open-questions]] #13); and (b) with the
+> *software* signer the key is on the same disk, so the attacker can re-sign and pass verification —
+> only a secure-element key ([[tpm]]/[[atecc608]]) closes that. [[tpm|TPM-sealed]] LUKS additionally
+> stops the disk **mounting** off-host at all.
 
 ### Business-layer event types (the ledger)
 

wiki/concepts/disk-os-hardening.md

@@ -2,7 +2,7 @@
 type: concept
 tags: [parking, security, platform]
 sources: [parking-system-architecture]
-updated: 2026-06-14
+updated: 2026-06-21
 ---
 
 # Disk / OS Hardening
@@ -18,6 +18,12 @@ Physical-access attacks on Windows are trivial (boot media + password-reset tool
 - **GRUB password + Secure Boot** — prevents boot-parameter tampering / unsigned loaders.
 - **No desktop environment** — single-purpose appliance.
 - **Key-based SSH only.**
+- **[[tpm|TPM 2.0]]** _(recommended, 2026-06-21)_ — seals the LUKS key to the boot chain so the disk
+  **auto-unlocks only on an untampered boot**, making encryption-at-rest compatible with **unattended
+  reboot** (a booth must come back up after a power cut without a human typing a passphrase). Also a
+  candidate home for the non-extractable host event-signing key. Caveats (live-root limit, bus-sniff,
+  PCR brittleness, mandatory recovery passphrase + re-seal runbook) on [[tpm]]; implementation is
+  [[open-questions]] #12.
 
 With LUKS in place, **SQLCipher becomes optional** defence-in-depth rather than the critical
 layer. (The custom controller adds its own: ESP32 flash encryption + secure boot — see

wiki/concepts/threat-model.md

@@ -13,8 +13,8 @@ The **second foundational force** (with [[offline-first]]). The central insight
 ## The key reframing
 
 Early thinking focused on protecting the database **at rest** — SQLCipher, LUKS, BitLocker,
-TPM-sealed keys. All of that defends against **an outsider who steals the machine or boots from
-external media**.
+[[tpm|TPM-sealed keys]]. All of that defends against **an outsider who steals the machine or boots
+from external media**.
 
 That is the **wrong primary threat**. The most likely adversary is the **legitimate operator at
 the booth**. While the app runs, the database is decrypted in memory and the operator has full

wiki/concepts/tpm.md

@@ -0,0 +1,95 @@
+---
+type: concept
+tags: [parking, security, platform, hardware]
+sources: []
+updated: 2026-06-21
+---
+
+# TPM 2.0 (Trusted Platform Module)
+
+A small crypto chip on the host that provides two host-hardening primitives. Useful **defence-in-
+depth** for the appliance, but — like all secure elements — it defends the **secondary**
+([[threat-model|outsider-with-the-box]]) threat, **never** the operator-at-the-booth, and is **not**
+a substitute for the system's real anti-fraud control ([[reconciliation]] over the
+[[append-only-event-chain|signed chain]]). _(Analysis recorded 2026-06-21; implementation pending —
+see [[open-questions]] #12.)_
+
+> ⚠ **Naming:** it's **TPM** (Trusted Platform Module), often miswritten "TMP".
+
+## How it works — two primitives
+
+1. **Non-extractable keys.** A key generated *inside* the TPM never leaves it. No command at any
+   privilege level reads out the private key; you can only ask the TPM to *use* it (sign/decrypt).
+   So the key isn't a file an attacker can copy — the same property the [[atecc608]] gives, but with
+   hardware most PCs already have.
+2. **Boot measurement + sealing (PCRs).** Each boot stage hashes the next (firmware → bootloader →
+   kernel) into tamper-evident registers (**PCRs**). A secret can be **sealed** so the TPM only
+   releases/uses it when the PCRs match a known-good boot state — tamper the boot chain → PCRs change
+   → the TPM refuses.
+
+## What it buys this appliance
+
+- **Sealed-LUKS auto-unlock for unattended reboot.** The headline win. LUKS ([[disk-os-hardening]])
+  normally needs a human to type a passphrase at boot; a parking booth must reboot itself after a
+  power cut. `systemd-cryptenroll --tpm2-device` seals the LUKS key to the TPM + boot-chain PCRs, so
+  the disk auto-unlocks **only** on an untampered boot. This is what makes "encrypted disk" and
+  "unattended appliance" compatible.
+- **Defeats the offline disk-tamper / re-sign attack.** If the host event-signing key lives in the
+  TPM (non-extractable), then pulling the SSD yields the *data* but **not** the signing key — so an
+  attacker cannot edit a row and re-sign the chain. `verifyChain()` then catches every edit. (With a
+  *software* signer the key sits in `.env` on the disk, so disk theft = key theft = forgeable; see
+  [[append-only-event-chain]] "Signer abstraction".) Sealed-LUKS goes further: the disk won't even
+  **mount** off-host, blocking the read step entirely.
+- **Boot tamper-evidence** complementing the already-decided Secure Boot + GRUB password
+  ([[disk-os-hardening]]).
+
+## What it does NOT protect against (be honest about the limits)
+
+- **A rooted *running* host.** The TPM stops key *theft*, not key *use*. An attacker with admin/root
+  on the live appliance can still ask the TPM to sign — the chip signs for whoever the running OS
+  authorizes. So a TPM does **not** make a compromised host trustworthy. (A per-op TPM auth PIN/policy
+  raises this bar but a determined root can often capture it.) This is exactly why the load-bearing
+  control stays [[reconciliation]] against an **external** authority that assumes the box may lie.
+- **Determined physical + BIOS access with tools.** Documented attacks exist:
+  - **Bus sniffing** — a *discrete* TPM talks to the CPU over an external LPC/SPI bus; researchers
+    have physically tapped it and captured secrets *as they're released* (e.g. the LUKS/BitLocker key
+    in transit) on PCR-only-sealed systems. A **firmware TPM (fTPM)** inside the CPU has no external
+    bus to sniff (but has had its own firmware bugs).
+  - **TPM 1.2 is broken** (SHA-1) — require **2.0** only.
+  - Vendor-specific firmware/reset/replay vulns have surfaced over the years.
+- **The operator (primary threat).** While the app runs, the DB is decrypted in memory and the
+  operator acts *through* the authenticated app — encryption/sealing is irrelevant to "take the cash,
+  void the record" ([[threat-model]]).
+- **Windows caveat.** On Windows the TPM serves BitLocker/Hello, not our Linux app; a Windows-admin
+  attacker inherits Windows' long history of BitLocker-TPM bypasses. Another reason the Windows + WSL
+  fallback ([[desktop-shell-tauri]]) is the weak deployment.
+
+## Verdict & guidance
+
+- **Recommended (not required)** on the **Ubuntu 26.04 LTS appliance** ([[desktop-shell-tauri|best
+  case]]): use it for **sealed-LUKS auto-unlock + a non-extractable host event-signing key**. It is a
+  **cost-raiser and theft-defeater, not an absolute vault.**
+- **Prefer a firmware TPM (fTPM)** (Intel PTT / AMD fTPM — no external bus to sniff) and add a
+  **PIN/auth policy**, rather than PCR-only sealing.
+- **Operational hazard:** sealing to boot-chain PCRs means a *legitimate* kernel / GRUB / BIOS update
+  also changes the PCRs and **locks you out** until re-sealed. Keep a **LUKS recovery passphrase** and
+  a **re-seal-on-update runbook** — mandatory, and a reason this stays "enhancement," not "baseline".
+- **It complements, never replaces,** the [[append-only-event-chain|signed chain]] +
+  [[reconciliation]].
+
+## TPM vs. ATECC608 — which secure element for the signing key
+
+Both can hold the non-extractable host event-signing key. Pick by platform:
+
+| | **TPM 2.0** | **[[atecc608]]** |
+| --- | --- | --- |
+| In a typical PC? | **Often yes** (discrete or fTPM) | **No** — an external I²C part you add/solder |
+| Standard / integration | TCG standard, OS-integrated | Microchip part, app-integrated over I²C |
+| Best fit here | **PC-based host appliance** (use what's there) | **Embedded / [[esp32-custom-controller|ESP32]]** controller |
+| Tangled with the whole OS attack surface? | Yes (general-purpose) | Less so (single-purpose chip) |
+
+**Implication (refines the prior framing):** the wiki/[[bom]] treated the ATECC608 as *the* host
+signing root, but for the **Ubuntu-PC appliance the TPM is the realistic host secure-element** (no
+extra part to source), with the **ATECC608 reserved for the embedded controller** where there's no
+TPM. Either delivers the tamper-*proof* property; see [[open-questions]] #6 (host secure-element by
+platform) and #12 (TPM hardening implementation).