Introduce a new role SUPPORTER that:

• Can view everything globally like ADMIN.
• Cannot perform modifying actions on data that is not their own (read-only on others’ resources).
• Can use the platform normally for their own data (profile, their projects/orgs, etc.).
• Can impersonate any user, with a read-only impersonation token that guarantees no changes can be made during impersonation.

High-level Approach

• Add SUPPORTER as a user role alongside USER and ADMIN.
• Introduce a "read-only mode" flag in the security context that can be triggered either because:
  • The authenticated platform role is SUPPORTER and is acting on resources they don’t own, or
  • The session is an impersonation session initiated with a read-only token.
• Enforce read-only:
  • API layer (HTTP method guards + explicit annotations for safe POST endpoints).
  • Method-level security (service-level guard in case endpoints circumvent HTTP verb semantics).
• Provide an endpoint to generate read-only impersonation tokens that encode “read-only” in claims; ensure the authentication pipeline respects this and blocks mutation.
• *Update UI to reflect read-only mode and disable modifying controls.

Acceptance Criteria

• A user with role SUPPORTER:
  • Can retrieve any resource (GET/HEAD/OPTIONS) across the platform.
  • Cannot create/update/delete resources they do not own; receives 403 with code read_only_mode.
  • Can perform full CRUD on resources they own (their profile, their organizations/projects).
• Read-only impersonation token:
  • Can be issued by ADMIN and SUPPORTER.
  • If issued by SUPPORTER, the token is always read-only; mutation is blocked even on the impersonated user’s own account.
• Frontend:
  • Read-only banner visible during read-only impersonation.
  • *Mutating controls are disabled.
• Tests:
  • Unit, integration, and E2E cover the above and pass in CI.
• Documentation:
  • OpenAPI reflects read-only rules.
  • Docs reflect the new SUPPORTER role.