fix(WRK-34): stop writing the watchdog correlation id into CommandMethod

ReportWatchdogFaultIfNeededAsync built the StaHung fault with
CommandMethod = snapshot.CurrentCommandCorrelationId, so the wire
fault's command_method field carried an opaque correlation id (or
empty) instead of a method name -- a consumer reading CommandMethod as
a method name got a confusing value. Use a stable "Watchdog" label and
fold the stuck command's correlation id (when present) into the
diagnostic message instead. No test asserts CommandMethod for the
StaHung fault; the existing assertions only check Category and that
DiagnosticMessage contains "STA activity is stale", both unchanged.

src/ZB.MOM.WW.MxGateway.Worker/Ipc/WorkerPipeSession.cs

@@ -1388,11 +1388,18 @@ public sealed class WorkerPipeSession
         // the StaHung fault just sent. Without this the heartbeat loop keeps
         // advertising a non-faulted state that contradicts the fault.
         _state = WorkerState.Faulted;
+        // WRK-34: CommandMethod is a method-name field, not a correlation-id field, so a
+        // consumer reading it (dashboard, gateway logs) shouldn't see a bare correlation id
+        // there. Use a stable label and carry the stuck command's correlation id (if any) in
+        // the diagnostic message instead.
+        string correlationSuffix = string.IsNullOrEmpty(snapshot.CurrentCommandCorrelationId)
+            ? string.Empty
+            : $" Stuck command correlation id: {snapshot.CurrentCommandCorrelationId}.";
         await TryWriteFaultAsync(
             CreateFault(
                 WorkerFaultCategory.StaHung,
-                snapshot.CurrentCommandCorrelationId,
-                $"STA activity is stale by {staleFor}."),
+                "Watchdog",
+                $"STA activity is stale by {staleFor}.{correlationSuffix}"),
             cancellationToken).ConfigureAwait(false);
     }