Repair inherited access and enforce conflicting-role boundaries

Edit role-review.json. roles contains unique {id,permissions,inherits}; assignments contains one {user,roles} for each supplied user; sessions contains one {id,user,activeRoles} for each supplied session, without changing its user. Referenced roles must exist and inheritance must be acyclic. Use only the seven supplied permission IDs. Bounds: at most 12 roles, 8 users and 12 sessions; each ID is ASCII letters, digits, hyphens or underscores, 1..60 characters. Arrays have no duplicate values. Repair all direct/transitive excess, current static assignment conflicts and current dynamic activation conflicts. Keep every required operation available: a rejected activation grants no permissions. separation has static and dynamic arrays of distinct two-permission pairs. Static needs [vendor-prepare,vendor-approve]; dynamic needs [invoice-prepare,invoice-approve]. Each may hold at most eight pairs. enforcement has assignment and activation, each reject or log. Log records a conflict but permits it. Future probes enumerate every role subset through actual inheritance; assignment proposals with a static conflict and authorized activation proposals with a dynamic conflict must be rejected. Safe current snapshots alone do not satisfy prevention. You may restructure role edges/permissions or redesign assignments; equivalent safe strategies are accepted. Legacy roles may remain unused. Review named failures, save partial progress, repair without Reset and rerun. Reset restores the unsafe starter. This simulated model permits different sessions for invoice duties and does not check per-invoice history.