feat(core): hold every analytics face to the dateRange array ARITY

The shared conformance kit had exactly one array-arm case — a two-element
window — so the arity itself was governed nowhere and each face was free to
invent a reading for `['2026-01-01']`, `[]`, `[a, b, c]` and `[null, null]`.

Adds `ANALYTICS_DATE_RANGE_NOT_A_WINDOW` and the case that holds every
REGISTERED face to the rule PR #17593 already landed on the service-analytics
faces: a non-two-bound array is refused with the ADR-0112
ANALYTICS_DATE_RANGE_UNRECOGNIZED / 400 envelope. No existing case is
weakened — the two-element window case is this one's control.

Claude-Session: https://claude.ai/code/session_01RuoNSXUbBoWHkNS4AknTrM
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

packages/core/src/utils/analytics-date-range-conformance.ts

@@ -70,8 +70,16 @@ export interface AnalyticsDateRangeFace {
   /**
    * Lower one `dateRange` and report the window. ⛔ Must let a refusal
    * PROPAGATE — the kit reads the thrown envelope's `code` and `status`.
+   *
+   * ⚠️ The array arm is `readonly unknown[]`, not `readonly string[]`: the
+   * ARITY case below drives shapes the schema's `z.array(z.string())` types
+   * away but a real caller still reaches a face with — `[]` and `[null, null]`
+   * among them (`POST /analytics/dataset/query` types its selection from
+   * `AnalyticsQuery` and never Zod-parses it). A runner whose own parameter is
+   * the narrower type still satisfies this — the declaration is a METHOD, so
+   * its parameter is bivariant — and needs no change.
    */
-  lower(range: string | readonly string[]): Promise<LoweredDateRangeWindow>;
+  lower(range: string | readonly unknown[]): Promise<LoweredDateRangeWindow>;
 }
 
 /**
@@ -106,6 +114,49 @@ export const ANALYTICS_DATE_RANGE_EXPLICIT_WINDOW: readonly [string, string] = [
   '2026-09-30T00:00:00.000Z',
 ];
 
+/**
+ * [#17596] ⛔ Array arms that do not denote a window — the ARITY case's inputs,
+ * each a shape an author or a generator really writes, ⛔ not fuzz.
+ *
+ * The kit's only array case used to be the two-element window above, so the
+ * arity itself was governed NOWHERE and every face was free to invent a
+ * reading for the rest. Four faces in one package had invented three —
+ * MEASURED on `abc4b83ce` (#17124), one authored document over the same rows:
+ * `['2026-01-01']` was a point window, an upper bound left unwritten, and a
+ * window dropped to ALL OF HISTORY, depending on which backend answered. A
+ * fifth face — `driver-memory`'s cube face — dropped it too (#17596, measured
+ * end to end: the one-element array emitted a pipeline byte-identical to one
+ * with no `dateRange` at all).
+ *
+ * ⭐ The rule asserted here is NOT invented for the kit: it is the one PR
+ * #17593 already landed on the `service-analytics` faces — a non-two-bound
+ * array is refused with the ADR-0112 `ANALYTICS_DATE_RANGE_UNRECOGNIZED` / 400
+ * envelope — stated once here so every REGISTERED face is held to it instead
+ * of one package pinning it for itself.
+ *
+ * ⛔ Why a refusal and not an alignment: all three readings are ungoverned, and
+ * teaching every face the same guess is the "align them independently" shape
+ * the kit exists to end. What IS governed is the contract the spec's own
+ * refusal wording states — *an explicit window is the two-element array
+ * [start, end]* — and the #16322 migration table, which tells an author to
+ * write a single day as `['2026-01-20', '2026-01-20']`. TWO bounds.
+ *
+ * ⚠️ The two-element window case above is this case's CONTROL and is load
+ * bearing: without it, "refuse every array" would satisfy the whole array arm.
+ */
+export const ANALYTICS_DATE_RANGE_NOT_A_WINDOW: readonly (readonly unknown[])[] = [
+  // The card's own shape: one bound, which is not a window.
+  ['2026-01-01'],
+  // No bounds at all — a generator that filtered its list to nothing.
+  [],
+  // Three bounds: which two? Every face that answered picked a different pair.
+  ['2026-09-01T00:00:00.000Z', '2026-09-30T00:00:00.000Z', '2026-10-31T00:00:00.000Z'],
+  // Two bounds of the right ARITY that are not dates — the shape that reached
+  // `parseUTC(null)` as a bare `TypeError` on one face, and lowered to the
+  // string `'null'` on another. Two bounds is necessary, not sufficient.
+  [null, null],
+];
+
 /** The three presets whose upper bound is NOW rather than a calendar boundary. */
 const ROLLING: readonly DateRangePreset[] = ['last_7_days', 'last_30_days', 'last_90_days'];
 
@@ -117,7 +168,7 @@ interface ThrownEnvelope {
 
 async function attempt(
   face: AnalyticsDateRangeFace,
-  range: string | readonly string[],
+  range: string | readonly unknown[],
 ): Promise<{ window: LoweredDateRangeWindow } | { refusal: ThrownEnvelope }> {
   try {
     return { window: await face.lower(range) };
@@ -185,6 +236,29 @@ export async function analyticsDateRangeConformanceFindings(
 
   // ── Everything else is REFUSED, with one envelope ────────────────────────
   const envelopes = new Set<string>();
+  /**
+   * ⭐ ONE judgement for every refusal this kit demands — the STRING arm's
+   * out-of-vocabulary spellings and the ARRAY arm's non-windows — so the two
+   * arms cannot drift into two envelopes for one condition. ⛔ The thrown
+   * MESSAGE is quoted only when there is no `code` at all, which is the case
+   * where the text is the only evidence of what the face actually did (a face
+   * that emitted no window and threw something of its own reads exactly like
+   * one that refused, until you read it).
+   */
+  const judgeRefusal = (input: unknown, refusal: ThrownEnvelope): void => {
+    if (refusal.code !== 'ANALYTICS_DATE_RANGE_UNRECOGNIZED') {
+      say(
+        `refused ${JSON.stringify(input)} with code ${String(refusal.code)}, `
+        + `not ANALYTICS_DATE_RANGE_UNRECOGNIZED`
+        + (refusal.code === undefined ? ` (${refusal.message ?? 'no message'})` : ''),
+      );
+    }
+    if (refusal.status !== 400) {
+      say(`refused ${JSON.stringify(input)} with status ${String(refusal.status)}, not 400`);
+    }
+    envelopes.add(JSON.stringify({ code: refusal.code, status: refusal.status }));
+  };
+
   for (const bad of ANALYTICS_DATE_RANGE_REFUSED_SPELLINGS) {
     const got = await attempt(face, bad);
     if ('window' in got) {
@@ -194,14 +268,29 @@ export async function analyticsDateRangeConformanceFindings(
       );
       continue;
     }
-    if (got.refusal.code !== 'ANALYTICS_DATE_RANGE_UNRECOGNIZED') {
-      say(`refused ${JSON.stringify(bad)} with code ${String(got.refusal.code)}, not ANALYTICS_DATE_RANGE_UNRECOGNIZED`);
-    }
-    if (got.refusal.status !== 400) {
-      say(`refused ${JSON.stringify(bad)} with status ${String(got.refusal.status)}, not 400`);
+    judgeRefusal(bad, got.refusal);
+  }
+
+  // ── [#17596] ARITY: an array that is not TWO bounds is not a window ───────
+  //
+  // ⭐ The rule PR #17593 landed on the service-analytics faces, stated once
+  // for every registered face. ⛔ Reported per SHAPE rather than as one
+  // verdict: which arities a face answers is the finding — a face that
+  // refuses `[]` and answers `['2026-01-01']` has not adopted the rule, it has
+  // grown a fourth reading.
+  for (const bad of ANALYTICS_DATE_RANGE_NOT_A_WINDOW) {
+    const got = await attempt(face, bad);
+    if ('window' in got) {
+      say(
+        `ANSWERED the ${bad.length}-element array ${JSON.stringify(bad)} with `
+        + `[${got.window.start}, ${got.window.end}] instead of refusing — an explicit window is `
+        + 'the TWO-element array [start, end], so every other arity is a window this face INVENTED',
+      );
+      continue;
     }
-    envelopes.add(JSON.stringify({ code: got.refusal.code, status: got.refusal.status }));
+    judgeRefusal(bad, got.refusal);
   }
+
   if (envelopes.size > 1) {
     say(`raised ${envelopes.size} different envelopes for one condition — ADR-0112 asks for one`);
   }