feat(security): OperationalAudit + AuditExport permissions for Audit Log surface (#23 M7)

Bundle G (#23 M7-T15): replace the temporary Admin-only gate on the Audit
Log surface with two new permission policies — OperationalAudit (read) and
AuditExport (bulk-export) — so the read path and the forensic-export path
can be delegated independently.

ScadaLink.Security
- AuthorizationPolicies: add OperationalAudit + AuditExport policy
  constants; register them via RequireClaim with an explicit role allow-list
  (OperationalAuditRoles, AuditExportRoles) so the role-to-permission
  mapping is documented in one place.
- Default mapping: Admin and Audit roles grant both policies; AuditReadOnly
  grants OperationalAudit only (read access without bulk export); Design
  and Deployment grant neither.

ScadaLink.CentralUI
- AuditLogPage: switch the page-level [Authorize] to the OperationalAudit
  policy and wrap the Export-CSV button in an AuthorizeView gated on
  AuditExport so an OperationalAudit-only operator still sees the page +
  filters but cannot trigger the CSV pull.
- ConfigurationAuditLog: switch from RequireAdmin to OperationalAudit so
  both pages under the Audit nav group share the same gate.
- NavMenu: the Audit nav group now gates on OperationalAudit so the
  section header + both child links match the per-page policies.
- AuditExportEndpoints: switch RequireAuthorization from RequireAdmin to
  AuditExport — this is the authoritative gate; the AuthorizeView on the
  button is just a UX affordance.

Tests
- New AuditLogPagePermissionTests covers the 5 brief-mandated cases plus
  defence-in-depth for Admin-alone and AuditReadOnly users on the endpoint.
- SecurityTests: add policy-level coverage for the new role→permission
  matrix (Theory rows pin every role/policy combination).
- AuditExportEndpointsTests: switch to AddScadaLinkAuthorization() so the
  test host exercises the real production wiring under the new gate.
- AuditLogPageScaffoldTests: wrap the page render in a
  CascadingAuthenticationState so the new in-page AuthorizeView resolves
  the principal.

src/ScadaLink.Security/AuthorizationPolicies.cs

@@ -3,12 +3,98 @@ using Microsoft.Extensions.DependencyInjection;
 
 namespace ScadaLink.Security;
 
+/// <summary>
+/// Centralised authorization policy names + the role→permission mapping
+/// that defines them.
+///
+/// <para>
+/// The codebase uses a thin role-claim model: each policy expresses a
+/// permission, satisfied when the principal carries any role claim
+/// (<see cref="JwtTokenService.RoleClaimType"/>) that maps to that
+/// permission. Role names are free strings configured via
+/// <see cref="ScadaLink.Commons.Entities.Security.LdapGroupMapping"/> rows
+/// (see <see cref="RoleMapper"/>) — there is no permission claim, just a
+/// fan-out from role to allowed policies.
+/// </para>
+///
+/// <para>
+/// Default role → permission mapping (#23 M7-T15 / Bundle G):
+/// <list type="table">
+///   <listheader>
+///     <term>Role</term>
+///     <description>Policies granted</description>
+///   </listheader>
+///   <item>
+///     <term><c>Admin</c></term>
+///     <description><see cref="RequireAdmin"/>,
+///     <see cref="OperationalAudit"/>, <see cref="AuditExport"/> — admins hold
+///     every permission by convention so an Admin-only user never loses
+///     access to a new surface.</description>
+///   </item>
+///   <item>
+///     <term><c>Design</c></term>
+///     <description><see cref="RequireDesign"/></description>
+///   </item>
+///   <item>
+///     <term><c>Deployment</c></term>
+///     <description><see cref="RequireDeployment"/></description>
+///   </item>
+///   <item>
+///     <term><c>Audit</c></term>
+///     <description><see cref="OperationalAudit"/>,
+///     <see cref="AuditExport"/> — the full audit surface (read + bulk
+///     export) per <c>Component-AuditLog.md</c> §"Authorization".</description>
+///   </item>
+///   <item>
+///     <term><c>AuditReadOnly</c></term>
+///     <description><see cref="OperationalAudit"/> only — operators who
+///     should see the Audit Log + drill in to incidents but not pull bulk
+///     CSV exports. Use this when delegating triage without granting
+///     forensic-export capability.</description>
+///   </item>
+/// </list>
+/// LDAP group → role mapping is configured via the central UI Admin → LDAP
+/// Mappings page (rows in <c>LdapGroupMappings</c>); the same code path
+/// reads them whether the role is one of the four built-ins above or any
+/// future addition. Adding a role here means adding the LDAP mapping row in
+/// the deployment; no schema migration is needed.
+/// </para>
+/// </summary>
 public static class AuthorizationPolicies
 {
     public const string RequireAdmin = "RequireAdmin";
     public const string RequireDesign = "RequireDesign";
     public const string RequireDeployment = "RequireDeployment";
 
+    /// <summary>
+    /// Read access to the Audit Log #23 surface (Audit Log page,
+    /// Configuration Audit Log page, Audit nav group). Granted to the
+    /// <c>Audit</c> role, the <c>AuditReadOnly</c> role, and the
+    /// <c>Admin</c> role.
+    /// </summary>
+    public const string OperationalAudit = "OperationalAudit";
+
+    /// <summary>
+    /// Permission to pull a bulk CSV export of the Audit Log. Separate from
+    /// <see cref="OperationalAudit"/> so a triage operator can read the
+    /// table without being able to exfiltrate it in bulk. Granted to the
+    /// <c>Audit</c> role and the <c>Admin</c> role.
+    /// </summary>
+    public const string AuditExport = "AuditExport";
+
+    /// <summary>
+    /// Roles that satisfy <see cref="OperationalAudit"/>. Held in one place
+    /// so the seed/docs and the policy stay in lockstep.
+    /// </summary>
+    internal static readonly string[] OperationalAuditRoles = { "Admin", "Audit", "AuditReadOnly" };
+
+    /// <summary>
+    /// Roles that satisfy <see cref="AuditExport"/>. A strict subset of
+    /// <see cref="OperationalAuditRoles"/> — read access does NOT imply
+    /// export permission.
+    /// </summary>
+    internal static readonly string[] AuditExportRoles = { "Admin", "Audit" };
+
     public static IServiceCollection AddScadaLinkAuthorization(this IServiceCollection services)
     {
         services.AddAuthorization(options =>
@@ -21,6 +107,19 @@ public static class AuthorizationPolicies
 
             options.AddPolicy(RequireDeployment, policy =>
                 policy.RequireClaim(JwtTokenService.RoleClaimType, "Deployment"));
+
+            // Multi-role permission policies — the policy succeeds when the
+            // principal holds ANY of the mapped roles. RequireClaim with
+            // multiple allowed values is the right primitive: it checks
+            // whether *any* role claim's value is in the allowed set, so a
+            // user with role=Admin (and nothing else) satisfies the
+            // OperationalAudit policy without needing a separate Audit
+            // role claim.
+            options.AddPolicy(OperationalAudit, policy =>
+                policy.RequireClaim(JwtTokenService.RoleClaimType, OperationalAuditRoles));
+
+            options.AddPolicy(AuditExport, policy =>
+                policy.RequireClaim(JwtTokenService.RoleClaimType, AuditExportRoles));
         });
 
         services.AddSingleton<IAuthorizationHandler, SiteScopeAuthorizationHandler>();