fix(lint): the new suite member keeps the #4463 P1 flow floor

Every member of the reference-integrity suite judges flow snapshots, pinned
as a roster-wide invariant rather than a per-member preference. The member
declares 'flow' to hold that floor; on a flow snapshot the objects are context
in both passes, so it adds a pass and no verdict. 'view' stays argued out —
a view write cannot change an object's own field-name lists.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012zGPuVVX3deAx9LdjK8jCk

Author: os-try2026

packages/lint/src/reference-integrity-suite.ts

@@ -239,9 +239,8 @@ export const REFERENCE_INTEGRITY_RULES: readonly ReferenceIntegrityRule[] = [
   // on a list view. Placed directly after them because it completes the same
   // sweep — every field name an object or its built-in views write down.
   //
-  // `runtimeTypes` is `['object']` — the ONLY member of this suite that names
-  // that type, and the only one that does not name `flow`. Both halves are
-  // deliberate.
+  // `runtimeTypes` is `['flow', 'object']` — the ONLY member of this suite
+  // that names `object`, and `flow` for the floor the suite keeps.
   //
   // It names `object` because that is the point of the member: Studio's app
   // builder mints no `view` items at all, so the list-view members have
@@ -253,15 +252,22 @@ export const REFERENCE_INTEGRITY_RULES: readonly ReferenceIntegrityRule[] = [
   // against the object's OWN field map, so a one-object snapshot is not
   // merely sufficient, it is the whole universe the question has.
   //
-  // It does NOT name `flow` or `view`, and that is not an omission. On either
-  // of those snapshots the objects are CONTEXT, present in the baseline and
-  // the candidate alike, so every finding this member could raise there
-  // cancels in the gate's differential (#4463 D4 — a stored object already in
-  // violation is never charged to someone else's write). Declaring them would
-  // buy two extra passes over the tenant's object model per flow write and
-  // change no verdict. CLI commands ignore this field entirely, so all three
-  // commands judge every object either way.
-  { name: 'validateObjectFieldRefs', runtimeTypes: ['object'], run: validateObjectFieldRefs },
+  // It names `flow` because EVERY member of this suite does — the #4463 P1
+  // surface is the floor the member axis was never meant to narrow, and
+  // `runtime-gate.view-writes.test.ts` pins it as an invariant over the whole
+  // roster rather than a preference per member. Worth being plain about what
+  // it buys here: on a flow snapshot the objects are CONTEXT, present in the
+  // baseline and the candidate alike, so anything this member could raise
+  // there cancels in the gate's differential (#4463 D4 — a stored object
+  // already in violation is never charged to someone else's write). So it
+  // adds a pass, not a verdict. That is the right trade against being the
+  // first member to leave the floor.
+  //
+  // It does NOT name `view`, and that IS an argued omission: the `crossed`
+  // list in that same test is written out precisely so each view crossing is
+  // argued, and this member judges no list view. A view write cannot change
+  // an object's own field-name lists.
+  { name: 'validateObjectFieldRefs', runtimeTypes: ['flow', 'object'], run: validateObjectFieldRefs },
   { name: 'validateActionNameRefs', run: validateActionNameRefs },
   { name: 'validatePageFieldBindings', run: validatePageFieldBindings },
   // [#14073] The same page, one question out. `validatePageFieldBindings`