RBAC: Authorize a workflow through scoped effective permissions

## Parent

- #806

## What to build

Deliver the first complete scope-aware authorization tracer through one representative workflow read experience. Elsa Server resolves `EffectivePermissions(subject, authorizationScope)` for exactly one selected tenant, expands catalog implications, treats permission claims as non-authoritative hints, and exposes the expanded set plus permission revision in the session contract. ASP.NET authorization and the FastEndpoints authoring adapter use that same decision.

Elsa Studio consumes the expanded session through one central permission service, protects the representative route and action, replaces tenant-scoped state on tenant switch, and refreshes on revision mismatch. During migration, known scope-compatible direct grants remain available only through a read-only resolver adapter.

Covers PRD user stories 31-38, 43-46, 52-56, 86, 93-96, and 98.

## Acceptance criteria

- [ ] One workflow read operation is authorized end to end by the same scope-aware effective-permission resolver through ASP.NET, FastEndpoints, session projection, and Studio.
- [ ] Role assignments and grants from tenant A never contribute to tenant B, including through caches, claims, sessions, or Studio state.
- [ ] Permission implications are expanded only by Server and produce identical results at the API and Studio surfaces.
- [ ] Foundation-managed role or assignment revocation changes the next request without requiring token renewal; permission claims cannot preserve revoked authority.
- [ ] The session contract exposes exact authorization scope, expanded permission keys, permission revision, grant-source summary, and external-grant freshness metadata.
- [ ] Studio replaces its permission set when the selected tenant changes and refreshes when Server reports a revision mismatch.
- [ ] The endpoint authoring adapter no longer relies on FastEndpoints' exact permission-claim check or unconditional wildcard composition.
- [ ] Known scope-compatible legacy direct grants are honored only through a read-only migration adapter; wildcard, unknown, and scope-incompatible grants remain excluded.
- [ ] The Server HTTP seam and Studio integration seam prove `401`, `403`, implication parity, tenant isolation, next-request revocation, tenant switching, and mixed old/new session behavior.

## Blocked by

- #828

Start with blocked issue #828, then trace the EffectivePermissions resolver through ASP.NET authorization, the FastEndpoints authoring adapter, the session contract, and Studio's central permission service. Validate the Server HTTP and Studio integration seams against the listed 401/403, implication-parity, tenant-isolation, revocation, tenant-switching, and mixed-session criteria.

Written by the indexing model from the issue text.