fix(fleetops): decode the QR image instead of asking the API for the uuid

[roncodes]

The two QR requests need the value a scanner reads — the tracking number's owner uuid, which is the one documented place the API takes a uuid rather than a public_id. Neither had a source: Decode Tracking Number QR sent the literal {{qr_code}} and Capture QR Code for Order sent an empty string.

Create a Tracking Number already returns qr_code, a base64 PNG generated from that uuid, and it is public on the TrackingNumber resource (unlike Order and Entity, where it is isInternalRequest()-gated). The after-response script now decodes it with jsqr + fast-png and sets {{qr_code}}.

This reproduces what a scanning device actually does, which is the right thing for the collection to demonstrate — and avoids exposing the raw uuid on the API, which is not what that endpoint is for.

Details worth noting

• One value serves both requests. captureQrScan resolves its subject as the order itself when no type is sent, and the tracking number is owned by {{order_id}} — so the decoded uuid matches $subject->uuid.
• The decode is guarded. If the runtime cannot resolve the npm packages, the catch logs and the run continues; the two QR requests then fail visibly on their own rather than an unhandled script error taking the whole collection down.
• The script also asserts the QR is decodable, so a tracking number that stopped carrying a readable code would be caught rather than silently skipped.

Requires Capture QR Code for Order to run after the tracking number exists — ordering change in fleetbase/fleetbase.

🤖 Generated with Claude Code