NodeLink EFS file-system policy admits any

IAM Access Analyzer (prod account analyzer and the org analyzer in the security account) reports the NodeLink shared storage `fs-02769ebfe9f7010b7` in prod as "allows public access" (MEDIUM, 2 findings open on 2026-10-17): the file-system policy the control plane writes (`apps/api/app/nodelinks.py`, the statements with `Principal: "*"`) restricts access to TLS and to access points but names no principal, account or organization, so the policy itself admits anyone who can reach a mount target. Scope the principal: add an `aws:PrincipalOrgID` (or `aws:PrincipalAccount`) condition to every Allow statement, keeping the TLS-only Deny and the access-point requirement, in both the control plane's writer and the terraform seed (`infra/jaah/terraform/shared-storage.tf`, `shared_efs_access_point_only`), and verify the Access Analyzer findings resolve after the next policy write. Check the out-of-VPC mount path (docs/policies/nodelink.md) still works: a host outside the VPC mounts with the account's IAM identity, so the org condition must admit it. Out of scope: changing which access points exist, the uid/gid enforcement, mount options, or anything about the storage's network path. Done means: - `aws efs describe-file-system-policy` on the prod store shows every Allow statement carrying a principal-scoping condition. - `aws accessanalyzer list-findings` (prod analyzer, us-east-1) shows the two EFS findings resolved or archived. - infra/jaah/test_shared_efs.py pins the condition in the terraform seed; a unit test pins it in nodelinks.py.

EFS NodeLink policy: every Allow now requires AccessedViaMountTarget (writer + tf seed + tests). PrincipalOrgID rejected: no-iam mounts would all be refused. Gate green (one stage timed out, re-run alone and passed). PR #5593 merged, dev deploy succeeded. Prod Repair + Access Analyzer check deferred to draft #6677.