feat(alarms): structural degraded-status signal for truncated alarm snapshots

The truncation-cliff fix made alarm transitions truncation-safe but silent:
when GetXmlCurrentAlarms2 returns exactly maxAlmCnt records the worker
suppresses absence-implies-Clear inference and says so only in a rate-limited
stderr warning. No client and no operator could tell a complete active set
from a capped one.

Two additive proto3 booleans carry the verdict out:

- QueryActiveAlarmsReplyPayload.snapshot_truncated = 2 (worker IPC reply)
- ActiveAlarmSnapshot.from_truncated_snapshot = 16 (per record)

The per-record field is not an aesthetic choice. QueryActiveAlarms returns a
bare `stream ActiveAlarmSnapshot` with no envelope, header, or trailer, so a
per-record boolean is the only carrier that stays wire-compatible; an envelope
message would change every existing client's stream element type. The reply
payload states it too because a prefix filter can leave zero records and a
truncated fetch with nothing to report still has to say so. The flag means
"this set may be incomplete", never "this record is unreliable" — it is
independent of the subtag-fallback `degraded` field.

Detection is deliberately UNCHANGED: IsTruncatedFetch remains
`fetchedRecordCount >= maxAlarmsPerFetch`. The live probe (docs/AlarmProbeFindings.md,
ce5d8ae) could not verify whether ALARM_RECORDS/@COUNT reports the total active
count or only the records in the reply, so @COUNT is not parsed for detection;
switching to it stays blocked on probe evidence. The probe's comment
annotations in WnWrapAlarmConsumer.cs are preserved.

Reset semantics: not latched. WnWrapAlarmConsumer.FoldFetch replaces the
verdict on every poll under the same lock as the snapshot merge, so the first
sub-cap fetch clears it; GatewayAlarmMonitor.ClearCache drops it with the cache
generation it describes. A caveat that never turns off is one operators learn
to ignore.

Flow: WnWrapAlarmConsumer.LastSnapshotTruncated -> AlarmDispatcher (stamps every
record) / IAlarmCommandHandler (payload) -> MxAccessCommandExecutor reply ->
GatewayAlarmMonitor._snapshotTruncated -> IGatewayAlarmService.SnapshotTruncated
-> DashboardAlarmQueryResult -> AlarmsPage warning banner (render-side only; the
poll loop and DisposeAsync drain are untouched). The public QueryActiveAlarms
RPC forwards worker snapshots unmodified, so the per-record flag needed no
mapper change — a test pins that.

Parity: this describes OUR fetch mechanics — additive gateway metadata — not
MXAccess provider behavior. No event is synthesized and no MXAccess-observable
semantics change, so it is not a parity deviation.

Tests: worker LastSnapshotTruncated set/reset/consecutive-burst (windev-run);
gateway end-to-end truncated reply -> monitor -> public stream, with the
complete-reply control as the load-bearing assertion; AlarmsPage banner
present/absent. Docs: gateway.md alarm surface, docs/DesignDecisions.md entry.

src/ZB.MOM.WW.MxGateway.Server/Dashboard/DashboardAuthenticator.cs

@@ -1,7 +1,9 @@
 using System.Security.Claims;
+using Microsoft.Extensions.Options;
 using ZB.MOM.WW.Auth.Abstractions.Ldap;
 using ZB.MOM.WW.Auth.Abstractions.Roles;
 using ZB.MOM.WW.Auth.AspNetCore;
+using ZB.MOM.WW.MxGateway.Server.Configuration;
 
 namespace ZB.MOM.WW.MxGateway.Server.Dashboard;
 
@@ -17,10 +19,15 @@ namespace ZB.MOM.WW.MxGateway.Server.Dashboard;
 /// </summary>
 /// <param name="ldapAuthService">Shared LDAP bind-then-search provider.</param>
 /// <param name="roleMapper">Maps LDAP groups to dashboard roles.</param>
+/// <param name="options">
+/// Gateway options supplying <c>MxGateway:Dashboard:GroupToTag</c>, the map that turns the user's
+/// LDAP groups into the dashboard visibility tags stamped on the cookie principal (SEC-25).
+/// </param>
 /// <param name="logger">Logger for diagnostic, credential-free login outcomes.</param>
 public sealed class DashboardAuthenticator(
     ILdapAuthService ldapAuthService,
     IGroupRoleMapper<string> roleMapper,
+    IOptions<GatewayOptions> options,
     ILogger<DashboardAuthenticator> logger) : IDashboardAuthenticator
 {
     private const string GenericFailureMessage = "The username or password is invalid, or the user is not authorized.";
@@ -70,7 +77,8 @@ public sealed class DashboardAuthenticator(
             ldapResult.Username,
             ldapResult.DisplayName,
             ldapResult.Groups,
-            roles));
+            roles,
+            options.Value.Dashboard.GroupToTag));
     }
 
     /// <summary>
@@ -97,12 +105,23 @@ public sealed class DashboardAuthenticator(
     /// is role-based), so the shape change is non-breaking for dashboard consumers.
     /// </param>
     /// <param name="roles">The dashboard roles resolved from <paramref name="groups"/>.</param>
+    /// <param name="groupToTag">
+    /// The configured <c>Dashboard:GroupToTag</c> map. The tags it grants are stamped as
+    /// <see cref="DashboardAuthenticationDefaults.DashboardTagClaimType"/> claims so a
+    /// cookie-authenticated circuit carries its grant without a hub-token round-trip — the
+    /// session-details page's in-process subscribe seam reads exactly these claims.
+    /// </param>
     private static ClaimsPrincipal CreatePrincipal(
         string username,
         string displayName,
         IEnumerable<string> groups,
-        IEnumerable<string> roles)
+        IEnumerable<string> roles,
+        IReadOnlyDictionary<string, string[]> groupToTag)
     {
+        // Materialized because the groups are read twice below (group claims and tag mapping) and
+        // the source is only guaranteed to be enumerable.
+        string[] groupNames = groups as string[] ?? [.. groups];
+
         List<Claim> claims =
         [
             // Keep NameIdentifier so any existing read-site that uses it continues to work.
@@ -120,9 +139,14 @@ public sealed class DashboardAuthenticator(
         // Groups are short RDN names from ILdapAuthService (see param doc above), so
         // this claim value is the short group name, not the original DN.
         // LdapGroupClaimType is MxGateway-specific ("mxgateway:ldap_group") — no ZbClaimType for groups.
-        claims.AddRange(groups.Select(group => new Claim(
+        claims.AddRange(groupNames.Select(group => new Claim(
             DashboardAuthenticationDefaults.LdapGroupClaimType,
             group)));
+        // Dashboard event-visibility tags (SEC-25). Visibility only — never a data-access grant —
+        // and never logged: only the decision, never the tag values, reaches diagnostics.
+        claims.AddRange(DashboardGroupTagMapping
+            .MapGroupsToTags(groupNames, groupToTag)
+            .Select(tag => new Claim(DashboardAuthenticationDefaults.DashboardTagClaimType, tag)));
 
         ClaimsIdentity claimsIdentity = new(
             claims,