Enforce project membership RBAC and administration #1300

Original author: Wassim Chegham (@manekinekko)

Context

This is the human authorization delivery under parent #17.
Implementation: PR #1532, project membership RBAC and administration.

Project-scoped queries already use projectId, and the API verifies human IdP
tokens and resolves enrolled Scope users. The remaining boundary is authorization:
a client's ?projectId=, CLI --project / SCOPE_PROJECT, or Portal selection
must never grant access merely because the client supplied it.

The original issue arose from the project-organization work associated with
#1241 and design #1210. Its old statement that authentication does not exist is
historical; this issue now tracks the policy layer above that authentication.

Problem

Structural project filters are not an authorization decision. The API must
verify that the authenticated caller may act on the canonical project and has
permission for the operation, including ID/reference/derived-resource lookups.
Portal controls and CLI flags cannot be the enforcement boundary.

Proposed resolution

• Enforce project memberships and operation permissions at the API, with
  explicit platform/project administration rather than client-selected authority.
• Apply policy consistently across API routes and expose compatible
  administration/access behavior in the Portal and CLI.
• Cover criteria creation/management/editing and run submission/backfill,
  preserving the original requirement from parent Deliver authentication and RBAC across Scope #17.
• Authorize against canonical project/entity records; IDs, slugs, references,
  bulk operations, and client-supplied projectId must not bypass scope.
• Keep explicit public endpoints and the existing human login/enrollment
  contract intentional. Deny access when required authority cannot be validated.
• Integrate verified service/job principals from Authenticate internal services with JWT #1557 at the route-policy
  boundary; do not require services to impersonate or enroll as human users.

Delivery boundaries and dependencies

RBAC auth-on rollout is blocked by #1557's service authentication. Coordinate the
principal/policy contract with PR #1532; this does not mean both issues must
block each other before implementation can proceed.

Human CLI token acquisition/storage/refresh/logout belongs to #1562.
Application service JWT handling and caller wiring belong to #1557.
JWT infrastructure is an assumed external foundation, not research to implement
in this issue. Report enablement is not introduced by this delivery.

Acceptance criteria

• Authenticated human requests are constrained by project memberships and
  operation permissions, with explicit administrator authority where intended.
• Changing projectId or using another entity's UUID/slug/ref cannot expose
  or mutate an unauthorized project's data.
• Policies cover point, list, referenced/derived-resource, and bulk paths
  consistently; criteria management and run submission/backfill are covered.
• API, Portal, and CLI access/administration behavior is consistent; hiding
  a control is never the only enforcement.
• Missing authentication returns 401; disallowed operations return 403
  where appropriate. Inaccessible project-scoped resources use the intended
  not-found behavior (404) from the RBAC design instead of exposing existence.
• Disabled/missing users, revoked memberships, incomplete authority changes,
  and authority-store failures deny access under the defined freshness/error
  contract rather than silently falling back.
• Auth-on registration/scanning and worker/judge workflows succeed with the
  non-human principals delivered by Authenticate internal services with JWT #1557, without a global admin bypass.
• Public probes and explicit human enrollment remain compatible, report
  exclusions remain explicit, and related architecture/API documentation is updated.

References

• Parent: Deliver authentication and RBAC across Scope #17.
• Implementation: PR feat: add project membership RBAC and administration #1532.
• Required service authentication: Authenticate internal services with JWT #1557.
• Human CLI authentication: Add CLI sign-in and JWT credential management #1562.
• External foundation:
  growth-ecosystems/scope-core-infra#150.
• Support runtime Portal authentication configuration #1450 - related Portal runtime configuration; coordinate rather than duplicate.
• Original project-organization context: feat: per-project data organization (implements #1210 design) #1241 and docs: Data Organization design doc — Projects #1210.
• [Archived PR] feat(auth): API uses Entra ID Authentication #1268 - archived historical authentication PR, not an outstanding prerequisite.
• docs/architecture/auth-rbac.md.