feat: team admin role

[msmithstubbs]

This PR adds an admin role which is required for destructive account actions.

• create/update/delete a team or backend requires team admin permission
• admin is granted to:
  • the team owner
  • a team user with admin role
  • an API request bearing a private:admin token

Team roles

• Adds role attribute to TeamUser, can be user or admin.
• All existing team users are user by default.
• admin permission (as detailed above) is required to update a team user role.

Access tokens and API scopes

• API tokens can be created with private:admin scope
• admin permission (as detailed above) is required to create private:admin tokens through the UI or API
• private:admin is a superset of private scope and is accepted where a private scope is required

Role management UI

The dashboard and account preferences will display and 'admin' label next to a team user with the admin role.

The term 'admin' can be ambiguous as we also have internal admins. I've used 'team admin' where possible to distinguish this. A team admin is a user with admin privileges for a team: either the team owner, or a team user with the admin role.

A team admin can add and remove other admins.

All team users created using the invite link as regular users. They can be granted team admin status after creation.

CleanShot.2026-01-06.at.10.34.49.mp4

If a team admin tries to remove their own admin role a warning is shown first.

CleanShot.2026-01-06.at.14.05.36.mp4

Users can create an API token with private:admin scope by checking Admin

Documentation

Updates documentation to include private:admin scope and note in OpenAPI spec.

Part of O11Y-1251 and O11Y-1149

[Ziinc]

should /api/sources/:token/backends/:backend_token require admin scope?

attaching sources to a backend doesn't need admin scope. fine to let users view the backends as readonly.

[depthfirst-app]

🟠 Severity: HIGH

Account takeover via email update. PUT /account/edit (update) calls Users.update_user_allowed(assigns.user, params) where assigns.user is the team owner. @user_allowed_fields includes :email and :provider_uid, allowing a team admin to change the owner's email address and effectively hijack the account.
Helpful? Add 👍 / 👎

💡 Fix Suggestion

Suggestion: The update action (and other mutating actions like delete, new_api_key, change_owner) should be restricted to the account owner only, not all team admins. There are two complementary approaches:

1. Scope the existing plug (line 8) to only cover read-only or safe actions: plug LogflareWeb.Plugs.AuthMustBeTeamAdmin when action in [:edit, :api_show]. Then add a separate owner-only guard for mutating actions. Since TeamContext.team_owner?/1 already exists and team_context is available in conn.assigns, you can create a lightweight AuthMustBeTeamOwner plug (analogous to the existing AuthMustBeTeamAdmin) that calls TeamContext.team_owner?(team_context) and apply it with plug LogflareWeb.Plugs.AuthMustBeTeamOwner when action in [:update, :delete, :new_api_key, :change_owner].

2. Additionally, remove :email and :provider_uid from @user_allowed_fields in lib/logflare/user.ex (or move them to a separate owner-only changeset). These are login-identity fields and should never be modifiable through a self-service update endpoint accessible to non-owning team admins. If email change is intentionally supported for the owner, create a separate owner_allowed_changeset/2 that includes those fields and call it only when the requestor is verified as the owner.