feat: /v1/role list, get, create, update and delete. Reassign members on delete. Write-time validation (ValidateGrants, duplicates, typed keys against real content types). Name uniqueness (role_name_taken), role_locked, role_has_members, role_conflict on version mismatch. No-escalation: nobody grants a permission they don't hold, and roles.edit_owner_only guards the Owner role. Activity events for role changes. Typed-key exposure in /auth/me. Cleanup of typed rows when a content type is deleted. | Backend only. Will carry the deferred ListGrants decision.

features/roles_permissions_foundation.feature

@@ -12,7 +12,7 @@ Feature: Roles and permissions foundation: catalogue, built-in roles, backfills
       - Scope with values none, own and all
       - Role {ID uint32, Name, Description, BuiltIn bool, Locked bool, Version uint32, Grants}
       - the sentinels ErrRoleNotFound and ErrUnknownPermission
-      - the Repository interface (list, get by id, get by name, list grants, create, save)
+      - the Repository interface (list, get by id, get by name, create, save; list grants was removed and delete, reassign members and remove typed grants added by roles_permissions_roles_api)
       - the pure function Role.Allows(key, owned bool) bool (superseded by roles_permissions_content_scope: Role.Allows and AllowsFor are removed, a role is evaluated through Role.GrantSet(), ScopeFor and Permits)
     And the catalogue is (kind: S = scoped none/own/all, B = on/off, "owner-only" = Owner only):
       | group    | key                         | kind | owner-only |
@@ -51,7 +51,7 @@ Feature: Roles and permissions foundation: catalogue, built-in roles, backfills
       | system   | system.edit_retention       | B    | yes |
       | system   | system.transfer_ownership   | B    | yes |
     And content permissions are stored under wildcard keys meaning "all content types"; per-type
-      overrides of the form content.<action>:<type_key> are deferred to slice 3 (the read side is implemented by roles_permissions_content_scope; writing them stays in slice 3)
+      overrides of the form content.<action>:<type_key> are written by slice 3, roles_permissions_roles_api (the read side is implemented by roles_permissions_content_scope; writing them stays in slice 3)
     And a role stores one row per granted key, with scope own or all. A key with no row is none or off.
       An on/off key that is on is stored as scope all.
     And three built-in roles are seeded by persistence/database (like SeedDefaultSite), idempotently,