[SEC-A-01] Role-based permissions are never enforced; `has_permission` ignores roles

[intendednull]

Commit: 2f26d91 · Finding: SEC-A-01

Problem

ServerState::has_permission at crates/state/src/server.rs:153-161 checks only the admin set and the peer_permissions map. It never looks at role grants, even though CreateRole, SetPermission, and AssignRole event kinds exist and populate state.roles + Member.roles.

pub fn has_permission(&self, peer_id: &EndpointId, perm: &Permission) -> bool {
    if self.admins.contains(peer_id) { return true; }
    self.peer_permissions
        .get(peer_id)
        .map(|perms| perms.contains(perm))
        .unwrap_or(false)
}

The test has_permission_ignores_role_based_permissions at crates/state/src/tests.rs:833 confirms the broken behaviour is intentional current code. This is a latent escalation/desync vector if a future code path begins honoring roles on one side and not the other.

Fix

Either:

• (a) Extend has_permission to union peer_permissions with the permissions of every role assigned to peer_id (state.roles[role_id].permissions for each role_id in member.roles). Also change SetPermission.permission to the typed Permission enum (see SEC-A-07).
• (b) Remove CreateRole/SetPermission/AssignRole until a real role model is wired in, and document that only direct GrantPermission works.

Obvious? Yes — the fix is straightforward but affects the authorization model. Not auto-PR'able without a design decision.