RBAC: Explain effective access and audit authorization changes

## Parent

- #806

## What to build

Give users and administrators a disclosure-safe explanation of effective access and a security audit trail for authorization changes. A subject can inspect its own current-scope grants; a tenant or host administrator can inspect subjects in that owned scope. Elsa Studio presents granting roles, implication paths, scoped external mappings, relevant constraint categories, permission revision, and mutation history without enumerating inaccessible subjects or resources.

Covers PRD user stories 37-38, 73-80, and 95-98.

## Acceptance criteria

- [ ] The effective-access API reports exact authorization scope, permission revision, explicit grants, granting roles, implication paths, external mapping sources, and disclosure-safe failed-constraint categories.
- [ ] Self inspection is limited to the subject's current scope; tenant and host administrators can inspect only subjects in their authorized scope.
- [ ] Unauthorized and cross-tenant explanation requests are redacted and non-enumerating.
- [ ] Role, template, assignment, service-principal, escalation, and authorization-policy changes emit audit records with actor, subject, scope, action, reason, correlation, source, timestamp, and relevant before/after permission keys.
- [ ] Audit records exclude credentials, bearer tokens, client secrets, secret values, and unredacted workflow payloads.
- [ ] Studio offers self-access and authorized scope-administration explanations plus filterable audit history with clear grant-source and constraint distinctions.
- [ ] Explanation and audit results update with the next Foundation-managed request after a role or assignment change.
- [ ] Server disclosure/security tests and Studio integration tests prove self/admin boundaries, tenant isolation, redaction, implication explanations, mutation history, and sensitive-data exclusion.

## Blocked by

- #830
- #832

Start with parent issue #806 and blocked issues #830 and #832 to understand the authorization model and prerequisites. Done means implementing disclosure-safe effective-access explanations, scoped audit history, Studio views, and the required server and Studio security tests described in the acceptance criteria.

Written by the indexing model from the issue text.