feat(permissions): add azure:members:write for member number changes

README.md

@@ -187,8 +187,8 @@ changing either without seeing what already exists makes no sense. The other imp
 are seeded defaults you can edit.
 
 The permissions that other PoliNetwork services check during the IdP–Telegram migration
-(`admin:access`, `tg:*`, `wa:groups:manage`, `groups:labels:write`, `web:*` and
-`azure:members:create`, see [RFC §4.1](docs/idp-telegram-integration-rfc-v3.md)) are seeded
+(`admin:access`, `tg:*`, `wa:groups:manage`, `groups:labels:write`, `web:*`,
+`azure:members:create` and `azure:members:write`, see [RFC §4.1](docs/idp-telegram-integration-rfc-v3.md)) are seeded
 as ordinary permissions, with `tg:immune` granting `tg:trusted`. No role is given them:
 Master Admin holds them through its wildcard, and administrators choose which roles grant
 them.

docs/idp-telegram-phase0.md

@@ -120,6 +120,8 @@ The owner answered Q1–Q8 on 8 October 2026. These are design decisions for the
 | Add `azure:members:create`                  | Authorizes the single create-socio workflow through the backend. It does not authorize arbitrary user updates or group operations.                                                                                                                        |
 | Remove proposed dashboard Azure permissions | Do not introduce `azure:members:read`, `azure:members:write` or `azure:groups:write` for the dashboard migration. The create-socio workflow is the only dashboard Azure capability in scope.                                                              |
 
+_Later amendment:_ `azure:members:write` was introduced after this phase, deliberately amending RFC v3 §4 decision 9, to let the dashboard change the member number of an existing user through `azure.members.setAssocNumber`. It authorizes no other user or group change. The tables in this section are kept as agreed in Phase 0.
+
 The create-socio workflow includes the necessary Entra user creation, profile and membership-number setup, addition of **that newly created user** to the fixed Soci group, and license assignment. The existing backend `createMember` code performs these steps; its Soci-group addition is an internal part of this one operation, not a general group-write permission. The backend must bind that addition to the user it just created and must not accept an arbitrary group ID or existing user ID for this operation. Existing `setAssocNumber`, group membership mutation and Azure browsing procedures are outside the dashboard's migration contract.
 
 **Role mapping (§4.2).** Treat the RFC's old-role mapping as migration context, not a fixed grant matrix. The IdP remains the sole source of global permissions. Administrators configure role grants in the IdP and may change them at runtime; no backend, bot or dashboard authorization check may depend on a role name. Managed-role membership and the Master Admin wildcard retain their existing IdP semantics. Before each caller is cut over, configure and review the initial grants needed for its operations; no Web Team or HR Telegram grant is prescribed here.

drizzle/0020_azure_members_write_permission.sql

@@ -0,0 +1,9 @@
+-- Changing the member number (Entra `employeeId`) of an existing socio returns to the admin
+-- dashboard, amending RFC v3 decision 9. The backend's `azure.members.setAssocNumber` checks
+-- this key, so seeding it keeps every environment spelled the same. It neither implies nor is
+-- implied by `azure:members:read` or `azure:members:create`. No role grant is seeded; Master
+-- Admin covers it through its wildcard. A permission an administrator already created by hand
+-- is left untouched.
+INSERT INTO "permission" ("id", "key", "name", "description", "managed") VALUES
+	('migration-permission-azure-members-write', 'azure:members:write', 'Change member numbers', 'Change the member number of an existing Microsoft 365 user and optionally email them the new number. No other user or group changes.', false)
+ON CONFLICT ("key") DO NOTHING;