fix(sonar): spell out the order these five sorts already have

SonarCloud's S2871 fires on a bare .sort() over strings and asks for localeCompare, and it
had five of them on new code, which is what put new reliability at D and failed the gate.

All five sort ISO dates or query parameter names, where the default lexicographic order is
exactly the one wanted. Taking the rule's suggestion literally would have been the wrong
fix twice over: a locale-aware comparison reorders dates differently per runtime, and on
the Amap signature it would produce a canonical string Amap itself does not compute, so
every signed request would come back rejected.

So the comparator is written out rather than changed. Byte order, explicitly, with a line
saying why it has to stay byte order. Behaviour is identical: the 43 Amap cases, the 40
track cases and the 30 client cases over these modules all pass unchanged.

client/src/components/Map/dawarichTrail.ts

@@ -130,7 +130,9 @@ export function collapsedDayDates(
     const foldedInPlan = !!expandedDayIds && !expandedDayIds.has(day.id)
     if (foldedInPlan || collapsedDayIds?.has(day.id)) dates.add(day.date)
   }
-  return [...dates].sort()
+  // Explicit rather than bare: these are ISO dates, where lexicographic IS chronological,
+  // and a locale-aware comparison would reorder them differently per runtime.
+  return [...dates].sort((a, b) => (a < b ? -1 : a > b ? 1 : 0))
 }
 
 /** The overlay as a GeoJSON FeatureCollection, for the GL renderer. */