test(plugin-security): the dependency-fault control's delegator is a member of the organization its agent runs in

The control cell "a delegator that resolves leaves the principal layer
neutral" runs on a walled stack (org scoping → isolated) whose delegator had
no membership row, so the explanation now answers the prologue's D10
organization-membership refusal there. Seed the membership, so the cell
measures what it names.

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

Author: claude

packages/plugins/plugin-security/src/explain-dependency-fault.test.ts

@@ -120,6 +120,11 @@ function makeEngine(schema: Record<string, unknown>, storeFaults: ReadonlyMap<st
     sys_record_share: [{ ...READ_SHARE }],
     // The delegator exists, so `resolveDelegatorContext` reaches the grant reads.
     sys_user: [{ id: U_REPORTER, email: 'reporter@example.com' }],
+    // [#25107] …and is a member of the organization the agent runs in. This
+    // stack is walled (org scoping → `isolated`), where a delegator with no
+    // membership there is refused before its grants matter (ADR-0090 D10), so
+    // the control below would deny for that reason instead of answering neutral.
+    sys_member: [{ id: 'mem_reporter_org1', user_id: U_REPORTER, organization_id: 'org1', role: 'member' }],
   };
   for (const [table, fault] of storeFaults) tables[table] = unavailableTable(fault);
   // `$or` / `$and` conjoin WITH their sibling keys, the way a real driver ANDs