test(driver-memory): pin the exclusive token end, and add the changeset

The `Intl.DateTimeFormat` fence dropped `fractionalSecondDigits` — it is not in
this package's `lib` view of `DateTimeFormatOptions` — and reads the sub-second
half off the window literal instead.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ADLdAs2pVcH17h9tZKWMBg

Author: claude

.changeset/memory-analytics-date-range-token-end-exclusive.md

@@ -0,0 +1,18 @@
+---
+"@objectstack/driver-memory": patch
+---
+
+`driver-memory` analytics: `dateRange: 'today'` no longer counts the first instant of tomorrow (#16179)
+
+`parseDateRangeString('today')` returns the day's start instant and the **next** day's start instant, and the analytics call site compared that upper bound with `$lte`. `nextUtcCalendarDay` widens only a bare `YYYY-MM-DD` and returns `null` for a full timestamp — its documented contract — so the half-open branch was never taken and the window closed at both ends. `'today'` was one day **plus one instant** long: two adjacent day windows overlapped at midnight and a row stamped exactly there was counted in **both**, silently.
+
+Measured through `MemoryAnalyticsService.query()` against the built package, rows at `2026-09-06T00:00:00.000Z` / `2026-09-06T12:00:00.000Z` / `2026-09-07T00:00:00.000Z`, clock frozen inside 2026-09-06:
+
+| `dateRange` | before | after |
+|:--|:--|:--|
+| `'today'` | all three, including `2026-09-07T00:00:00.000Z` | the first two |
+| `['2026-09-06T00:00:00.000Z', '2026-09-07T00:00:00.000Z']` | all three | all three — **unchanged** |
+
+⭐ **An explicit `dateRange: [a, b]` is deliberately untouched.** `$lte` on a caller-written timestamp end is the reading this package publishes today, and narrowing it would silently change what an existing query answers; the repair is confined to what the driver's own preset resolution emits. A bare-day end likewise keeps its whole-day widening (`< nextUtcCalendarDay(day)`).
+
+⚠️ Behaviour change for a caller using `dateRange: 'today'`: a row stamped at exactly the next day's midnight — `00:00:00.000` in the query's timezone — moves out of today's answer and into tomorrow's. That is the double-count being removed, not coverage being lost.

packages/drivers/driver-memory/src/memory-analytics-date-range-token-end-exclusive.test.ts

@@ -138,12 +138,14 @@ const iso = (t: number) => new Date(t).toISOString();
  * asserted to be a local midnight by this function.
  */
 function localClock(instant: string, zone: string): string {
+    // ⛔ No `fractionalSecondDigits`: it is not in this package's `lib` view of
+    // `Intl.DateTimeFormatOptions`. The sub-second half is checked directly on
+    // the literal instead — see the fence below.
     return new Intl.DateTimeFormat('en-CA', {
         timeZone: zone,
         hourCycle: 'h23',
         year: 'numeric', month: '2-digit', day: '2-digit',
         hour: '2-digit', minute: '2-digit', second: '2-digit',
-        fractionalSecondDigits: 3,
     }).format(new Date(instant));
 }
 
@@ -253,10 +255,13 @@ describe("#16179 — 'today' stops BEFORE tomorrow's first instant", () => {
     it('every window literal is a local midnight in its own zone — checked against `Intl`, not against the code under test', () => {
         for (const c of CELLS) {
             for (const bound of c.window) {
+                // The clock half, from the tz database.
                 expect(
                     localClock(bound, c.zone),
                     `${label(c)}: ${bound} is not midnight in ${c.zone}`,
-                ).toMatch(/ 00:00:00\.000$/);
+                ).toMatch(/ 00:00:00$/);
+                // The sub-second half, read off the literal itself.
+                expect(bound, `${label(c)}: ${bound} carries a sub-second part`).toMatch(/\.000Z$/);
             }
         }
     });