v3: realtime order changes, reassignment, order chat and bookings

[roncodes]

What and why

Navigator v3's side of the order operations program (shared contract: realtime order.changed, reassignment, order chat, service bookings, per-item meta). An audit of v3 found realtime switched off, order screens that never refetched, no v3 push handling, reassigned orders left on the device, an unreachable Offers screen, and a proof-capture loop. This PR fixes those and adds the contract's driver-facing surfaces.

1. Realtime was off

• App.tsx now passes the same SocketCluster config v2 builds (resolveConnectionConfig('SOCKETCLUSTER_*')) to V3App; before, SocketProvider mounted with enabled=false.
• SocketProvider holds the socket in state. Child effects run before the provider's, so useDriverChannel got a no-op and never subscribed again; listen now changes identity once the socket exists and subscribers re-run. A reconnect bumps live refresh. (Test: SocketProvider.test.tsx mounts a subscriber before the socket and receives an event.)

2. Event map

Added order.changed (summary, changes), order.updated, order.driver_unassigned, order.assigned_notification (OrderAssigned notification), and chat message events. The order id is also read from data.id. Unknown events are still dropped but logged in __DEV__. The open order is followed on order.{id}.

3. Order detail refetches

The order (GET orders/{id}), tracker and next step reload on order events and on focus.

4. v3 push handling

V3App takes subscribeToPush (App.tsx adapts v2's NotificationProvider). A foreground push is applied as the socket event it duplicates. A tapped push opens the order (order_changed, order_assigned, …), the Orders list (order_unassigned) or the conversation (chat_message_received) through a root navigation ref. If the container isn't ready yet, the navigation waits for it.

5. Reassignment

order.driver_unassigned and order_unassigned remove the order. Driver-scoped list queries now reconcile the store: rows they listed before and no longer return (within the page's window) are removed. Active ones are marked reassigned. Screens holding the order pop to the top of their stack, and Orders and Today show "Order FLE… was reassigned".

6. Changed-order banner and navigation

The order shows a "This order changed" banner with the server's summary. When changes includes dropoff, the banner offers Re-open navigation. Navigate targets the current stop (current_waypoint, else the drop-off). The hand-off now takes the order id and reads the order's current destination from the store, so it no longer relies on a snapshot in route params.

7. On the order

• Item quantities (meta.quantity), item notes, unavailable items and substitutes (meta.substitute_for).
• Cash on delivery: the amount is payload.cod_amount, shown as "to collect" per meta.payment.state. Orders without meta.payment (older ones) treat the amount alone as due. The completing step waits for I collected ….
• Delivery instructions (drop-off place meta.instructions / instructions) and order notes.
• The scheduled window or booking slot.
• Customer Call and Message, and Message dispatch.

8. Offers

Only adhoc orders are offered: they appear on the Offers screen and are taken with start + assign, as before. An order assigned to the driver is simply theirs; there is nothing to accept. Offers is reachable from the Orders screen. (Direct offers with a countdown were built here and removed in d6282b1, together with fleetbase/fleetops#398.)

9. Chat

• Channels are followed on chat.{id} and chat_channel.{id}, and chat pushes are routed.
• The Inbox badge is v3's own unread total; v2's ChatContext count is no longer used.
• Order-linked threads (meta.order_public_id) are labelled in the Inbox and the conversation header. On the order, the driver thread backs "Message dispatch" and the group thread backs "Message customer".
• System messages (meta.system) render as notices, and senders carry role labels (Store, Customer, You).

10. Flow

• "Finished" comes from the order config's complete flag, falling back to the old sets. This replaces the hard-coded sets in orderStore, OrdersScreen and useOrderRecord.
• Configs are cached outside React so the store's views can use them, and list queries prefetch them.
• The next step comes from GET orders/{id}/next-activity when the server answers. It has already evaluated the flow's logic, so a branch is offered as one button per option instead of "ask dispatch". Otherwise the app falls back to the client-side sequencer.
• Proof loop: a capture is recorded against its order and activity (persisted). Returning from capture advances once, with the proof id, instead of reopening capture.

11. Bookings

Orders with meta.is_booking read as a Job, with the slot and a Bring to the job checklist built from the order's entities. booked and provider_enroute have registry entries and labels, and confirmed ranks second in the lifecycle.

Blocked on / depends on server work

• order.changed broadcast and the order_changed / order_unassigned pushes, plus order.driver_unassigned on driver.{public_id} (Storefront edit service and Fleet-Ops, 1.1–1.3). Until then the banner never shows and reassignment relies on list reconciliation.
• Order chat: the app can't open an order thread. POST v1/chat-channels accepts no meta, and no driver-side orders/{id}/chat route exists, so "Message customer" uses a group thread only when one exists (else SMS to the customer's phone) and "Message dispatch" falls back to a new conversation. Channel meta is already returned. Participant meta.role and message meta.system are not yet on core-api's public ChatParticipant / ChatMessage resources, so role labels and system notices appear once those ship.
• meta.payment (contract 3) for the "to collect" state. Older orders fall back to payload.cod_amount.
• Bookings: meta.is_booking / meta.booking and the storefront-booking flow (contract 6).

Validation

• yarn typecheck (tsc -p tsconfig.v3.json): 15 errors, all pre-existing in v2 files pulled in by v3 (src/components/CameraCapture.tsx, src/hooks/use-app-theme.ts). The base branch has the same 15 and there are none in v3.
• yarn lint: 600 errors / 419 warnings, against 600 / 411 on the base. The errors are all pre-existing (v2 tree, scripts, jest setup), and running eslint on the files changed here reports no errors.
• yarn test: 69 suites, 1016 tests pass, up from 965. New tests:
  • events, push, applyEvent and SocketProvider (subscribe-before-connect, unassignment)
  • order store reconcile, and reassignment
  • config-driven finished status
  • proof ledger
  • order detail: change banner, re-open navigation, current-stop navigate, refetch on event, items, COD gating, server next-activity, no proof re-capture, reassignment, booking, contact and threads, instructions
  • chat: system notice, role labels, order thread in the inbox
• Not run on a device or simulator.

Docs

No docs or API spec changes from this PR. The endpoints and events it uses are defined by the order-operations contract and documented with the server PRs (fleetops, storefront, core-api).