updates on bugs on the dispatch and ai button integrations

tests/lib/ZoneContext.test.jsx

@@ -224,7 +224,7 @@ describe('ZoneContext', () => {
       return setup();
     };
 
-    it.each(['hubid', 'sourcehubid', 'applocationid', 'tenantlocationid', 'locationid'])(
+    it.each(['hubid', 'sourcehubid', 'servicinghubid', 'pickuphubid', 'nearesthubid'])(
       'should match on a direct %s',
       (field) => {
         const { result } = selectKoramangala();
@@ -232,6 +232,30 @@ describe('ZoneContext', () => {
       }
     );
 
+    // CHANGED. These three used to be asserted as matches, and that was the
+    // bug rather than the contract.
+    //
+    // A staff zone is a HUB. `applocationid` numbers cities, `tenantlocationid`
+    // and `locationid` number a client's own sites — so matching them against a
+    // hub id is a category error that lands orders in cities they never touched.
+    // A delivery row carries several at once (queries.js sets servicinghubid,
+    // applocationid and tenantlocationid together): DM-626241 is servicinghubid
+    // 5, Bangalore Earth Hub, alongside tenantlocationid 3, which read as a hub
+    // id is Hyderabad Mars Hub.
+    //
+    // The old `??` chain hid it by stopping at the first non-null field, so the
+    // collision only fired when the earlier fields happened to be missing.
+    //
+    // A tenant session is the mirror image and keeps its own assertions below:
+    // there the zone IS a tenantlocationid, and hub ids are the wrong space.
+    it.each(['applocationid', 'tenantlocationid', 'locationid'])(
+      'should NOT match a staff hub zone on a %s — different id space',
+      (field) => {
+        const { result } = selectKoramangala();
+        expect(result.current.matchesZone({ bookingid: 1, [field]: '2' })).toBe(false);
+      }
+    );
+
     it('should match a numeric hub id against the string zone id', () => {
       const { result } = selectKoramangala();
       expect(result.current.matchesZone({ hubid: 2 })).toBe(true);