fix(security): wrap the ConfigDb key store on admin nodes + registration guard

src/Server/ZB.MOM.WW.OtOpcUa.Host/OpcUa/ApiKeyOpcUaUserAuthenticator.cs

@@ -18,9 +18,18 @@ namespace ZB.MOM.WW.OtOpcUa.Host.OpcUa;
 ///         <b>This runs inline on session activation.</b> The SDK raises <c>ImpersonateUser</c>
 ///         synchronously while holding a SessionManager-wide event lock, so a slow authenticator does not
 ///         stall one request — it serializes every session activation server-wide. That is why
-///         verification is a single indexed lookup plus one HMAC, and why there is no directory call,
-///         no retry, and no network I/O on this path at all. It is the main practical advantage of keys
-///         over the LDAP bind this replaces.
+///         verification is a single indexed lookup plus one HMAC, with no directory call and no retry —
+///         the main practical advantage of keys over the LDAP bind this replaces.
+///     </para>
+///     <para>
+///         ⚠️ <b>"No network I/O" is TRUE ONLY ON A DRIVER-ONLY NODE</b> (arch-review 03/S18). The claim
+///         describes <see cref="ArtifactApiKeyStore"/>, which is two dictionary probes on an in-memory
+///         snapshot. On an <b>admin or fused</b> node <see cref="IApiKeyStore"/> is
+///         <see cref="ConfigDbApiKeyStore"/>, and a UserName activation costs <b>two</b> EF round trips
+///         (the key row, then the principal's <c>NodeAcl</c> rows) — inside this same lock. What bounds
+///         that is <see cref="BoundedApiKeyStore"/>, which wraps it in production; the deadline it applies
+///         surfaces here as an ordinary throw and is denied by the catch-all below, like any other store
+///         failure.
 ///     </para>
 ///     <para>
 ///         <b>Fail closed, and say little.</b> Every rejection returns the same opaque message. The