fix: service account handler eligibility for manager role

[rohan-chaturvedi]

🔍 Overview

Members with the default Manager role were never provisioned as Service Account handlers, so they held no copy of SA keyrings and couldn't perform any operation requiring them — generating tokens for client-side-KMS SAs ("Cannot create token: you are not a handler...") or enabling server-side key management ("You do not have handler access to this service account"). Since escaping the first error requires the second operation, Managers were fully locked out of client-side SAs. SSK-enabled and team-owned SAs were unaffected.

Root cause: default roles store an empty permissions JSON in the DB (their permissions resolve at runtime from the default_roles template), but resolve_service_account_handlers — the query deciding who gets SA keys wrapped for them — filtered on the stored JSON. Every default role except Owner/Admin (rescued by name) was silently excluded, while the UI resolved permissions from the template and advertised the operations as permitted.

💡 Proposed Changes

• Resolve handler eligibility in Python — from the default_roles template for default roles, stored JSON for custom roles. Custom-role semantics unchanged; net change to the eligible set is exactly + default Manager.
• Explicitly exclude the default Service role (machine-account role; humans holding it must not receive key custody).
• Exclude members without an identity_key (key ceremony incomplete) — wrapping for them is impossible and throws client-side.

🖼️ Screenshots or Demo

N/A — backend-only.

📝 Release Notes

Fixed: default-role Managers are now provisioned with Service Account handler keys, enabling token generation and key-management operations. Applies to newly created SAs immediately; pre-existing SAs are healed the next time an Owner/Admin changes a member's role to one with Service Account permissions (triggers an org-wide re-wrap).

🧪 Testing

• New: backend/tests/graphene/queries/test_service_accounts.py (10 tests) pins the eligibility contract per role type.
• Full backend suite: 1087 passed; 1 pre-existing environmental failure (test_file_read_permission_error, container runs as root), unrelated.

🎯 Reviewer Focus

The eligibility predicate in backend/backend/graphene/queries/service_accounts.py. Key invariant: the new eligible set is a strict superset of the old — UpdateServiceAccountHandlersMutation delete-and-recreates handler rows from this list, so a shrunken set would revoke existing key custody.

✨ How to Test the Changes Locally

1. As an Owner, create a client-side-KMS Service Account; add a member with the default Manager role.
2. As the Manager, create a token or switch the SA to server-side KMS — both fail before this fix, succeed after (for SAs created post-fix; for older SAs, first trigger a re-wrap by changing any member's role as Owner/Admin).

💚 Did You...

• Ensure linting passes (code style checks)? (no backend lint step in CI)
• Update dependencies and lockfiles (if required) — N/A
• Update migrations (if required) — N/A
• Regenerate graphql schema and types (if required) — N/A
• Verify the app builds locally?
• Manually test the changes on different browsers/devices? (bug repro confirmed on dev; fix covered by unit tests)