test(dogfood): the sweep's SELECTION scope on the real driver stack

The differential control the branch never had: `sched_org_sweep`, a
`time_relative` flow declared for org A, with matching rows in BOTH A (one) and
B (two). The discriminating number is the count of LAUNCHED RUNS — 1 with the
fix, 3 on the defect — because a pin asserting only "A's row was touched"
passes on the defect too.

Three properties, three producers:
 - selection: exactly one run, and it names A's record;
 - the data plane: `update_record` lands on A's row and on no other (the half
   the branch left unpinned — the earlier fixture flow was start -> notify ->
   end, so nothing would have gone red if the run's narrowing were wrong);
 - disclosure: no `sys_notification` names a B record. An unscoped sweep emits
   that notification BEFORE its write silently matches nothing, so a fix that
   narrowed only the writes would leave the leak open.

The memory limb answers the other question the card is about: a store with no
tenant isolation REFUSES the scoped sweep (#16589) and the failure is reported
at `error` naming the flow, with a paired control proving the refusal is about
the scope and not about the fixture (the same query unscoped still sees all
three rows).

The fixture object gains `due_date` as `datetime`, not `date`: the window is a
pair of ISO instants, and a column the driver truncates to YYYY-MM-DD would put
a per-driver truncation rule between the fixture and the property under test.

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

Author: claude

packages/qa/dogfood/test/fixtures/schedule-organization-fixture.ts

@@ -9,13 +9,23 @@
 // `sys_organization` ids and the recipient's `sys_user` id. A fixture that
 // baked either one in would assert against a row that does not exist.
 
-/** Object the tick touches, so a run has a data write of its own to land. */
+/**
+ * Object the tick touches, so a run has a data write of its own to land.
+ *
+ * `due_date` is what the `time_relative` sweep selects on (#16659 F2). It is a
+ * `datetime` rather than a `date` deliberately: the window the trigger computes
+ * is a pair of ISO-8601 instants, and comparing them against a column the
+ * driver truncates to `YYYY-MM-DD` puts a per-driver truncation rule between
+ * the fixture and the property under test, which is WHICH ORGANIZATION's rows
+ * came back.
+ */
 const SweepTargetObject = {
   name: 'sched_org_target',
   label: 'Sweep Target',
   fields: {
     name: { type: 'text', label: 'Name', required: true },
     touched: { type: 'checkbox', label: 'Touched' },
+    due_date: { type: 'datetime', label: 'Due' },
   },
 };
 
@@ -94,3 +104,75 @@ export function organizationLessScheduleFlow(recipientId: string): unknown {
   });
   return { ...declared, name: 'sched_org_undeclared', nodes };
 }
+
+/**
+ * [#16659 F2] The `time_relative` twin: a sweep that declares its acting
+ * organization, selects `sched_org_target` rows whose `due_date` falls in the
+ * next week, and — once per matched record — notifies and writes.
+ *
+ * Both trailing nodes are load-bearing and they measure DIFFERENT halves:
+ *
+ *  - `notify` produces one tenant-scoped inbox row per LAUNCHED run, so the
+ *    count of those rows is the count of records the sweep SELECTED. That is
+ *    the F2 property: an unscoped sweep selects the other organization's rows
+ *    too and posts about them into the declared organization's inbox.
+ *  - `update_record` is the data-plane half the branch previously left unpinned
+ *    (the fixture flow was `start → notify → end`). The run is scoped to the
+ *    declared organization, so a write aimed at another organization's row
+ *    matches nothing — silently. Asserting WHICH rows got `touched` is what
+ *    makes that narrowing observable instead of assumed.
+ */
+export function declaringTimeRelativeFlow(organizationId: string, recipientId: string): unknown {
+  return {
+    name: 'sched_org_sweep',
+    label: 'Time-relative sweep (organization declared)',
+    type: 'schedule',
+    status: 'active',
+    runAs: 'system',
+    nodes: [
+      {
+        id: 'start',
+        type: 'start',
+        label: 'Daily sweep',
+        config: {
+          timeRelative: {
+            object: 'sched_org_target',
+            dateField: 'due_date',
+            withinDays: 7,
+          },
+          organization: organizationId,
+        },
+      },
+      {
+        id: 'notify',
+        type: 'notify',
+        label: 'Due soon',
+        config: {
+          topic: 'sched.due',
+          recipients: [recipientId],
+          title: 'Due soon: {record.name}',
+          message: '{record.name} is due.',
+          channels: ['inbox'],
+          sourceObject: 'sched_org_target',
+          sourceId: '{record.id}',
+        },
+      },
+      {
+        id: 'touch',
+        type: 'update_record',
+        label: 'Mark touched',
+        config: {
+          objectName: 'sched_org_target',
+          filter: { id: '{record.id}' },
+          fields: { touched: true },
+        },
+      },
+      { id: 'end', type: 'end', label: 'End' },
+    ],
+    edges: [
+      { id: 'e1', source: 'start', target: 'notify' },
+      { id: 'e2', source: 'notify', target: 'touch' },
+      { id: 'e3', source: 'touch', target: 'end' },
+    ],
+  };
+}