Resolve Server-031..032 (re-triaged) + Server-038..043

Server-031: re-triaged. The recommended gateway-side
"skip-while-command-in-flight" guard is already in place at
WorkerClient.HeartbeatLoopAsync via WorkerClientOptions.HeartbeatStuckCeiling
(default 75s = 5× HeartbeatGrace). Two regression tests pin the
behaviour. Recommendation #1 (decouple worker-side _writeLock) is a
Worker-module concern (Worker-017 / Worker-023) and out of scope here.

Server-032: re-triaged. Recommendation #2 (rich diagnostic) is already
in EnqueueWorkerEventAsync, with #3 (overflow grace) absorbed by the
TryWrite → WriteAsync-with-timeout fall-through. Test
EnqueueWorkerEvent_WhenChannelFullPastTimeout_FaultsWithRichDiagnostic
pins the diagnostic string. Recommendation #1 (prose contract in
gateway.md / docs) is deferred — outside this pass's edit scope.

Server-038 (Security): EventsHub.SubscribeSession's missing per-session
ACL is documented with a TODO(per-session-acl) and a <remarks> block
explaining the v1 acceptance (any dashboard role can subscribe to any
session — non-secret metadata, redacted value logging). The per-session
ACL design lands in a follow-up once a session-scoped role exists.

Server-039 (Error handling): HubTokenService.Validate now rejects a
deserialized payload where both Name and NameIdentifier are null/empty.
New test file HubTokenServiceTests.cs covers the regression and five
sanity cases. TDD confirmed.

Server-040 (Conventions): MapGroupsToRoles gains a precedence comment
explaining "full literal match first, leading-RDN fallback;
OrdinalIgnoreCase via DashboardOptions.GroupToRole". Documentation-only.

Server-041 (Design adherence): EventStreamService.ProduceEventsAsync
wraps the broadcaster.Publish call in try/catch (Exception). The
producer loop and gRPC stream are no longer at the mercy of the
broadcaster's never-throw discipline. New regression test
StreamEventsAsync_WhenDashboardBroadcasterThrows_StillYieldsEventsAndDoesNotFaultSession.

Server-042 (Performance): DashboardSnapshotPublisher.ExecuteAsync now
mirrors AlarmsHubPublisher's reconnect loop — wraps the await foreach
in a while-not-cancelled, catches general exceptions, and Task.Delays
5s before retrying. An internal ctor accepts a shorter delay for the
test. New test file DashboardSnapshotPublisherTests.cs covers the
throw-then-yield reconnect path and the normal-completion case.

Server-043 (Documentation): HubTokenService class XML doc gains a
<remarks> describing the singleton lifetime, the two consumer scopes
(DashboardHubConnectionFactory scoped, HubTokenAuthenticationHandler
transient), and the thread-safety contract.

Verification: dotnet build src/ZB.MOM.WW.MxGateway.slnx clean
(0 warnings / 0 errors); src/ZB.MOM.WW.MxGateway.Tests 486/486 passing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/ZB.MOM.WW.MxGateway.Server/Dashboard/Hubs/EventsHub.cs

@@ -23,6 +23,29 @@ public sealed class EventsHub : Hub
 
     public static string GroupName(string sessionId) => $"session:{sessionId}";
 
+    /// <summary>
+    /// Subscribes the calling SignalR connection to the per-session events
+    /// group, so that events broadcast by
+    /// <see cref="DashboardEventBroadcaster"/> for that session reach this
+    /// client.
+    /// </summary>
+    /// <remarks>
+    /// Server-038: in v1 the hub-level <see cref="AuthorizeAttribute"/>
+    /// (<c>HubClientsPolicy</c>) only checks that the caller carries one of
+    /// the dashboard roles (Admin or Viewer); both roles may subscribe to
+    /// any session id they choose. This is acceptable today because (a) the
+    /// dashboard's per-session views show non-secret session metadata that
+    /// any authenticated dashboard user can already see, and (b) value
+    /// logging in the source gRPC stream is gated by the same redaction
+    /// policy that protects logs. The per-session ACL that gates the gRPC
+    /// <c>StreamEvents</c> RPC is intentionally not yet mirrored here.
+    /// TODO(per-session-acl): once a role/scope is introduced that scopes a
+    /// Viewer to a specific session or tenant, add a session-access check
+    /// at this seam — either inline (consult the per-user allowed-session
+    /// set on <c>Context.User</c> claims / <c>Context.Items</c>) or via a
+    /// dedicated authorization policy applied to the hub method itself.
+    /// </remarks>
+    /// <param name="sessionId">Session id to subscribe the caller to.</param>
     public Task SubscribeSession(string sessionId)
     {
         if (string.IsNullOrWhiteSpace(sessionId))