feat(scan): read Code 128 tracking barcodes; change list for structured tracking codes

[roncodes]

Companion to fleetbase/fleetops#356, which changes what tracking labels encode:

• QR: a versioned tracking url, https://<console>/track-order?order=<tracking number>&r=<owner public_id>&v=1. It used to be the owner's bare uuid.
• Barcode: Code 128 carrying the bare tracking number. It used to be PDF417 with the uuid.

capture-qr accepts the new url, a bare tracking number or public id, and the bare uuid on labels already in circulation. The app keeps working with old and new labels without this PR, because it sends the raw scanned value and the server decides.

This PR

• QrCodeScanner (used by ProofOfDeliveryScreen) and the legacy ProofScreen also scan code-128, so a driver can scan either code on a label. A smudged QR can fall back to the barcode.
• QrCodeScanner's onScan is now typed with vision-camera's Code. It has always passed the result object, not a string. The v2 screen already reads data.value; the type now says so.

Change list for the app (not in this PR)

1. v3 ProofCaptureScreen sends the scanner's whole result object as code (feature/v3-redesign, Navigator v3 — Waypoint redesign, expansion and refactor #109). It types onScan as (code: string), but QrCodeScanner passes the vision-camera Code, so:

   • scanned holds objects;
   • the "already scanned" check prev.includes(code) never matches, so re-scanning a parcel after the 3s cooldown counts it twice;
   • useProofCapture posts an object as code.

   The server has always rejected that, and still does, with "Unable to validate QR code data." (400). Fix: onScan={(code) => onScanValue(code.value)}, and keep scanned as strings. With this PR's typing, that branch stops compiling once it merges main, which is the point.

2. When v3 wires up expected (the scan checklist, currently never passed): compare by the tracking number inside the code, not the raw string. A QR scan is now a url, and older labels hold a uuid. Parse it with new URL(value).searchParams.get('order'), fall back to the raw value for a bare barcode, and compare without regard to case. Don't treat a uuid as a mismatch; let the server decide it.

3. Optional, scan-to-open: the url's r parameter is the owner's public id (order_…, waypoint_…, entity_…). An in-app scanner can open that record directly, or call POST tracking-numbers/from-qr, which resolves every format within the driver's company.

4. Don't depend on the host or the route. The host varies by install, and the public tracking page is being rebuilt, so its route will change; a later form may carry the tracking number in the path (/track/<number>). On the device, read r and v from the query and treat an unknown v as best effort. For the tracking number, or anything authoritative, send the raw value to the server (capture-qr or from-qr), whose parser follows every form.

5. Displaying codes: the barcode image is now a wide 1D barcode, about 330×60px at native size, not a squarer PDF417. The order and entity screens size it at 190×80 and w-40 h-18 (legacy), which squash it. That's fine for display, but give it a wider box if drivers are expected to scan it off the phone screen.

Testing

Verified through CI. To check on a device: scan a newly printed label's QR, then its barcode, then an old label's QR, on an order with pod_method: scan. All three should record a "Verified by QR Code Scan" proof.