Granular permissions for Attik Admin (per-feature / per-settings access)

Problem

Attik Admin access today is effectively all-or-nothing for users who should use the admin portal:

• isAttikAdmin is a single boolean on the user; only super-admin can toggle it (Settings → Users → “Attik Admin Access”).
• Once enabled, the Attik Admin UI does not expose a user-facing way to limit which admin areas a person can see or change.
• Admin navigation is hardcoded (e.g. Client Care, Settings in adminNavButtons.tsx); there is no per-user or per-role breakdown of admin capabilities.
• Admin Settings inner nav uses permissions: null on all links—nothing gates individual settings pages by permission today.

This forces a choice between no platform-level admin access and full access to admin features/settings, including areas that can affect multiple instances or sensitive configuration. Teams need principle of least privilege: grant only the admin features a role actually needs.

Desired outcome

Introduce permissioned access to individual Attik Admin features and settings so that:

• Certain users can use specific admin tools (e.g. Client Care, or a subset of Settings) without blanket authority to change settings across all instances.
• Navigation and routes enforce the same rules (hide or disable UI and reject API/backend actions when unauthorized).
• Clear model for who assigns these permissions (e.g. super-admin vs a new “admin permission manager” role) should be defined as part of design.
• Permissions will need to be added on the user

Context / notes

• Tools app: “Attik Admin” entry in user menu is gated by session.user.isAttikAdmin.
• Admin subdomain layout currently only requires an authenticated session; finer-grained checks should align with whatever permission model we add.

Acceptance criteria (draft)

• [ ] Document permission matrix for Attik Admin surfaces (nav items, settings sub-pages, destructive actions).
• [ ] Implement assignable permissions (or roles) that map to those surfaces.
• [ ] UI reflects permissions (nav + deep links); unauthorized URLs return 403 or redirect with clear messaging.
• [ ] Backend / BFF validates the same permissions for mutating operations.
• [ ] Migration path: existing isAttikAdmin users mapped to a default permission set (e.g. full parity with today) unless adjusted.