fix(deploy): a node with a ConfigDb records its degraded apply on its own NodeDeploymentState row (#601 review)

The apply writes the node's row Applied/null before the address-space outcome
is known; central adds the reason only when it ACCEPTS the ack, so a discarded
(stale/timed-out) ack left a fused node's row reading clean. The prefix moves
to ApplyAck.DegradedReasonPrefix so both writers spell the row identically.

Claude-Session: https://claude.ai/code/session_01Ef2ozxS7QPanGT8uoATbTe

src/Server/ZB.MOM.WW.OtOpcUa.ControlPlane/Coordinators/ConfigPublishCoordinator.cs

@@ -93,7 +93,7 @@ public sealed class ConfigPublishCoordinator : ReceiveActor, IWithTimers
     ///     degraded node DID apply the revision, so its status stays <see cref="NodeDeploymentStatus.Applied"/>
     ///     and the degradation rides the existing reason column, which <c>/fleet</c> already renders.
     /// </summary>
-    public const string DegradedReasonPrefix = "Applied degraded: ";
+    public const string DegradedReasonPrefix = ApplyAck.DegradedReasonPrefix;
 
     /// <summary>
     ///     Gitea #601 — whether a <c>NodeDeploymentState</c> row records a degraded apply: status