[geekypunk]

Why

Writes were gated on the built-in ADMIN or DBA role name, in both AccessControlService.currentUserMayMutateSql and the frontend's useAuth. A custom role could never write. That made it impossible to give EXECUTE_DDL (added in #130) to only some DBAs: a custom "DBA + schema changes" role would lose UPDATE/INSERT/DELETE entirely.

What changes

• New EXECUTE_WRITES permission, held by ADMIN and DBA by default, so no one's access changes on deploy.
• The backend and frontend gates check the permission, not the role name. A DBA whose EXECUTE_WRITES is revoked by an override can no longer write; a custom role granted it can.
• No re-login needed. Every authentication path (JWT, MCP token, View-as) loads effective permissions as authorities per request, so the check takes effect immediately.
• The Editor's "DBA mode" label is now "Write mode", since custom roles can see it.

Test plan

• AccessControlServiceTest uses production-shaped authorities (ROLE_* plus permission names), with new cases for a custom role granted writes and a role name alone granting nothing
• 80 tests across the auth, policy and safety-scanner suites
• eslint: 0 errors
• After deploy, create a custom role with DBA permissions plus EXECUTE_WRITES and EXECUTE_DDL, and assign it to the DBAs who need schema changes

🤖 Generated with Claude Code