fix(driver-memory): $options without $regex is refused too — the one operator the allowlist would have leaked

Measured after the vocabulary landed: `{ field: { $options: 'i' } }` still
escaped the ADR-0112 envelope on the live path (`unknown query operator
$options`, no code, no status) while the reference matcher ignored it and
matched EVERY row. #5324's exact shape, surviving for a single operator —
because `$options` is in the vocabulary as a MODIFIER of `$regex`, not a
predicate, so allowlisting the key without requiring its partner left the hole
open for it alone.

Refused when no `$regex` accompanies it, on both faces, and pinned.

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

Author: claude

packages/plugins/driver-memory/src/filter-refusal.ts

@@ -259,6 +259,28 @@ export function malformedBetweenError(field: string, value: unknown, path: strin
   );
 }
 
+/**
+ * [#5324] `$options` without the `$regex` it modifies.
+ *
+ * `$options` is in {@link SUPPORTED_FIELD_OPERATORS} as a MODIFIER, not a
+ * predicate — it carries the regex flags (`memory-matcher` reads it as
+ * `new RegExp(target, condition.$options)`, and objectql's `having` skips it for
+ * the same reason). On its own it is not a filter at all, and the two faces
+ * proved it: mingo raised `unknown query operator $options` — uncoded, the very
+ * escape #5324 is about — while the matcher ignored it and matched EVERY row.
+ * Allowlisting the key without requiring its partner would have left exactly one
+ * operator still leaking out of the envelope.
+ */
+export function danglingRegexOptionsError(field: string, path: string): Error {
+  return unsupportedFilterError(
+    `Operator "$options" on field "${field}" at ${path} has no "$regex" to modify. "$options" ` +
+      `carries the flags of a regex predicate (e.g. { "${field}": { "$regex": "abc", "$options": "i" } }); ` +
+      `it is not a predicate on its own. It is refused rather than ignored because the two ` +
+      `evaluation paths answered it differently — one raised an uncoded engine error, the other ` +
+      `matched every row (#5324).`,
+  );
+}
+
 /** [#5324] `$and`/`$or` take a list of nodes; anything else is refused. */
 export function filterNodeListExpectedError(key: string, value: unknown, path: string): Error {
   return unsupportedFilterError(
@@ -365,6 +387,9 @@ function assertFieldConstraintShape(field: string, spec: unknown, path: string):
       throw malformedBetweenError(field, spec[op], `${path}.$between`);
     }
   }
+  // `$options` is the one entry in the vocabulary that is a modifier rather than
+  // a predicate, so it is the one that needs a companion.
+  if (keys.includes('$options') && !keys.includes('$regex')) throw danglingRegexOptionsError(field, path);
 }
 
 /**

packages/plugins/driver-memory/src/memory-filter-vocabulary-refusal.test.ts

@@ -153,6 +153,22 @@ describe('[#5324/#5328] a filter this driver cannot evaluate is refused, not ans
     });
   }
 
+  it('refuses "$options" with no "$regex" to modify, on both faces', async () => {
+    // The one entry in the vocabulary that is a MODIFIER rather than a
+    // predicate, and therefore the one that could be allowlisted into a fresh
+    // leak: measured before this arm existed, `{ stage: { $options: 'i' } }`
+    // still escaped as an uncoded `unknown query operator $options` on the live
+    // path while the matcher ignored it and matched EVERY row — #5324's exact
+    // shape, surviving for a single operator.
+    const where = { stage: { $options: 'i' } };
+
+    const live = await liveRefusal(where);
+    expectEnvelope(live);
+    expect(live.message).toContain('has no "$regex" to modify');
+
+    expect(matcherRefusal(where).message).toBe(live.message);
+  });
+
   it('names the position, so a refusal deep in a scope tree is actionable', async () => {
     const err = await liveRefusal({ $or: [{ owner: 'u1' }, { $and: [{ stage: { $sounds_like: 'won' } }] }] });
     expectEnvelope(err);