feat: enforce domain-layer authorization on privileged store operations (#69)

[andregoepel]

Fixes #69 (the domain-layer half of #41).

Problem

UserStore / RoleStore performed privileged mutations (assign role, delete, restore, role management) with no authorization of their own — the only gate was the page-level [Authorize]. A single forgotten attribute, a permissive host FallbackPolicy, or any caller reaching a store directly became a privilege-escalation path (self-assign Administrator → full takeover). This is #41's tracked root cause, previously closed without a domain-layer fix.

Approach

New IIdentityAuthorizer provides a defense-in-depth check independent of the UI:

• DB-authoritative admin check — queries the live UserRoleAssignment / Role projection (not claims; per [architecture] Default-deny authorization + defense-in-depth in the domain layer #41 "the acting identity from claims proves identity, never authority"), and fails closed for an unidentified (Guid.Empty) caller.
• Guards on the operations that are never legitimately anonymous:
  • UserStore.AddToRoleAsync / RemoveFromRoleAsync → require Administrator (throw IdentityAuthorizationException; these return Task). This is the headline escalation vector.
  • UserStore.DeleteAsync → require Administrator or account ownership.
  • UserStore.RestoreAsync and all RoleStore mutations → require Administrator (return IdentityResult.Failed / NotAuthorized).
• BeginSystemScope() — an explicit, ambient (AsyncLocal) escape hatch so trusted server-side code (seeding, background provisioning, alternative bootstrap) can bypass the checks deliberately.

Why CreateAsync / UpdateAsync are not guarded

ASP.NET Identity legitimately drives them through anonymous flows — registration, password reset, email confirmation, failed-login lockout — with no authenticated principal. Their real authorization is the reset/confirmation token at the UI layer; a role/ownership check in the domain layer would break those flows. This is documented in THREAT-MODEL.md, and the stale-UpdateAsync-overwrite concern remains tracked in #70.

Why bootstrap doesn't deadlock

First-run root creation runs through CreateAsync, which appends the RoleAssigned / RoleCreated events directly (not via the guarded methods), so the first admin is created without needing a pre-existing admin.

Tests

• New UserStoreAuthorizationTests (9 cases): non-admin and anonymous actors are denied (role ops throw; delete/restore return NotAuthorized); admin and self are allowed; BeginSystemScope() bypasses.
• Existing persistence/invariant tests run under a permissive authorizer (they don't test authz), so RemoveFromRole_RootUserAdministrator_IsRefused still reaches the root invariant.
• Full suite: 187 unit + 68 Blazor + 71 integration. Build 0 warnings; CSharpier clean.

Out of scope (documented)

Page-level default-deny (FallbackPolicy / AuthorizeRouteView) remains a host obligation — this PR is the domain-layer defense-in-depth half.