updatess on the ui changs

src/pages/api/api.js

@@ -71,7 +71,11 @@ const BOOKING_STATUS_TO_DELIVERY_STATUS = {
   delivered: 'delivered',
   cancelled: 'cancelled'
 };
-const mapBookingStatusToDeliveryStatus = (status) => {
+// Exported (not just module-local) so anything else that needs to classify a
+// raw booking status — the operator bot's status-breakdown intent included —
+// reuses this instead of growing a second copy of BOOKING_STATUS_TO_DELIVERY_STATUS
+// that can drift from it.
+export const mapBookingStatusToDeliveryStatus = (status) => {
   const key = String(status || '').toLowerCase();
   return BOOKING_STATUS_TO_DELIVERY_STATUS[key] || key;
 };
@@ -636,9 +640,12 @@ export const fetchDeliveries = async ({ pageParam = 1, queryKey }) => {
       // meant an order re-stamped during the evening silently jumped out of the
       // batch it was actually assigned to and into whichever window contained
       // the current clock time — the same orders appearing under Afternoon and
-      // then Evening on the same day. Both now bucket on
-      // `expecteddeliverytime`, which is stable. It remains fine to DISPLAY
-      // this as a "last updated" stamp, which is all the reports use it for.
+      // then Evening on the same day. Both now bucket on `orderdate` (this
+      // row's `createdat`, immutable) instead — see dispatch/CLAUDE.md §1's
+      // table for why `expecteddeliverytime` was also tried and rejected (it's
+      // the promised delivery slot, not the wave the order was placed in). It
+      // remains fine to DISPLAY assigntime as a "last updated" stamp, which is
+      // all the reports use it for.
       assigntime: b.updatedat,
       orderstatus: mapBookingStatusToDeliveryStatus(b.status),
       droplat: b.deliverylatitude,