fix(rbac): fail closed when the anti-escalation guard cannot resolve a role

[remyluslosius]

The defect

RoleGrantsWithin returned true (allow) for every role missing from BuiltInRoles. Its comment justified this: an unknown role confers no permissions, so it is trivially within the caller's grant.

That holds for a typo. It does not hold for a custom role, which exists, is not built in, and passes the downstream existence check. So the guard waved through every custom role on both paths that use it: role assignment and API-token minting. The one function whose entire job is to fail closed was failing open on the only case it could not evaluate.

It is inert today because custom-role permissions are never enforced (Identity.HasPermission reads BuiltInRoles only). That is what makes it a landmine rather than a live breach: wiring enforcement would have made every waved-through grant real, retroactively.

Correcting the backlog while fixing it

The backlog says the path opens "for anyone with role:write+role:assign". Only admin holds both, and admin already holds credential:write and remediation:execute, so that actor gains nothing. The reachable paths are narrower and different:

1. Token minting needs only token:write, which security_admin holds. Once enforcement lands, a security_admin could mint a token bound to an existing custom role granting more than they hold.
2. An admin who delegates role management via a custom role hands the holder a route to grant themselves anything.

Both are real. Neither is the one described.

Both halves, because either alone leaves a two-step escalation

• The guard now denies an unresolvable role. RoleGrantsWithinResolved takes a RoleResolver so a legitimate custom role is evaluated on its actual permission set from the roles table rather than blanket-refused. A nil resolver, a missing row, or a query error all deny. Fail-closed on a DB fault is deliberate: failing open there is the same defect by another route.
• CreateCustomRole now rejects authoring a role granting a permission the creator lacks (403, naming them). Guarding only the assign step still lets a caller author an over-broad role and wait for someone else to assign it.

Negative-tested

Reintroducing the original return true fails AC-19:

guard must DENY an unresolvable role; returning true here is the escalation

SDD

system-rbac 1.1.0 -> 1.2.0, AC-19 (fail-closed guard) and AC-20 (authoring subset check). 116 specs, 116 passing. AC ids checked for collision this time, after the AC-13 duplicate in #763.

Not in scope

Wiring custom-role enforcement into Identity.HasPermission. That is a feature, and it is now safe to build.