GHSA-wrr4-782v-jhwh neotoma has tenant isolation gap in relationship query endpoints

• npm neotoma: >= 0.13.0, < 0.14.0 → fixed in 0.14.0

Summary The `/list_relationships` and `/retrieve_graph_neighborhood` endpoints call `getAuthenticatedUserId` (confirming a valid session exists) but do not pass the resolved user ID into the Supabase query as an `.eq("user_id", userId)` filter. As a result, queries return rows from all users rather than scoping to the authenticated caller's data. Affected code `/list_relationships` (`src/actions.ts`): • Calls `getAuthenticatedUserId` but does not apply `.eq("user_id", userId)` to the relationships query • Uses `.or()` string interpolation for entity ID matching without input validation `/retrieve_graph_neighborhood` (`src/actions.ts`): • Same pattern: auth resolved, user ID not applied to query filter Affected versions v0.13.0 Prerequisites 1. A valid authentication token for the Neotoma instance (attacker must have a legitimate account on the same instance) 2. A known entity ID belonging to another user (~96 bits of entropy — brute-force not practical) An unauthenticated caller is rejected at the auth middleware layer. The gap requires a second user account on the instance. Impact An authenticated user with a known cross-user entity ID can retrieve relationship edges and graph neighborhood data belonging to another user. No write capability is exposed. Severity Low under current conditions — no multi-tenant deployments exist. Escalates to Medium the moment two or more user accounts share an instance. Remediation 1. Add `.eq("user_id", userId)` to all Supabase queries in both handlers 2. Validate entity ID inputs with `isNeotomaEntityId` before query construction 3. Replace `.or()` string interpolation with separate scoped `.eq()` calls Fix tracked in #365 (list_relationships) and #366 (retrieve_graph_neighborhood). Gate gap tracked in #372.