Proposal: an 'operator' team role between member and admin

[Jedvanaways]

Since v4.2.0 the member role is read-only. I understand why that change was made, but it leaves a gap: there is now no role for day-to-day users who need to actually run things (create apps/services/databases, deploy, restart, manage env vars) without handing them full admin.

Admin currently also brings: server terminal access, managing team members and invitations, connecting GitHub/GitLab apps, private keys, cloud provider credentials and elevated API tokens. For a lot of teams that is exactly the stuff you don't want to hand out just so someone can deploy their own app. This has come up before: #11321 (closed, works as intended since 4.2), and granular permissions were suggested in #5292 and #11070.

Proposal: a new operator role that sits between member and admin.

What an operator can do (roughly what member could do before 4.2, plus resource creation):

• create/update/delete/deploy applications, services and standalone databases
• manage projects and environments
• env vars, scheduled tasks, backups to already-configured storage, tags, preview deployments

What an operator cannot do (anything that grants access outside the Coolify UI, or that would outlive a role change):

• terminal / command execution (the canAccessTerminal gate stays admin+)
• manage team members, invitations or roles
• servers, proxy config, private keys, cloud provider credentials
• add or modify GitHub/GitLab app sources (can use existing ones when creating an app)
• S3 storage credentials, notification settings, instance settings
• elevated API token abilities (same as member today: read-only tokens)

Implementation-wise it slots into the existing policy system without touching current behaviour: a new case in the Role enum ranked between MEMBER and ADMIN, team-scoped helpers on User alongside isAdmin()/isAdminOfTeam(), and only the resource-lifecycle policy methods opt in. isAdmin() itself is unchanged, so everything sensitive stays admin-only by default. The role column is already a plain string on team_user, so no migration is needed and downgrade is safe.

I have a working implementation with tests that I can PR to next if this is something you would take.