Scan demo

Pick a mode — receiving for tracking labels, inventory for product UPCs.

Stub. Actions fire a toast and return to the scan screen. No SKU lookup, no ledger writes.

Why two scan buttons. Carrier tracking numbers (Code 128) and retail UPCs/EANs can have the same digit length — a 12-digit FedEx Ground number and a 12-digit UPC-A both fit ^\d{12}$. Forcing the operator to pick a mode at scan time eliminates that ambiguity: receiving initialises the decoder with CODE_128 only; inventory initialises it with the retail UPC/EAN set. Faster decode per frame, no cross-mode collisions, the action set after the scan is whichever the mode produced.

Manual entry still classifies via UPC-A check-digit validation as a fallback (the user types something with no mode context); that path is what handles the FedEx-vs-UPC-A overlap when typed.

The real Receive / Transfer / Open Product flows are specified in docs/architecture/overview.md §10. The ScannedInput abstraction here (ADR-011) lifts as-is when those flows are built.