docs(acl): correct the API-key revocation warning after live verification (#520)

The /apikeys page claimed revocation "takes effect on a node only after the next
deployment". The live gate showed that is wrong for the node the operator is
most likely looking at: revoking through the UI denied the key on the VERY NEXT
request against the fused admin+driver node, because ConfigDbApiKeyStore reads
per request. The deployment delay applies only to driver-only nodes, whose keys
ride the artifact.

Reworded to say both, and to tell an operator to assume the slower behaviour when
revoking a compromised key — which is the decision the warning exists to inform.

Found by doing the thing rather than reasoning about it: the previous wording
looked obviously correct until the revoked key was actually re-presented.

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

src/Server/ZB.MOM.WW.OtOpcUa.AdminUI/Components/Pages/ApiKeys.razor

@@ -15,8 +15,11 @@
     whose password is the key below. The key resolves to a <strong>principal</strong>; ACL rows naming
     that principal are what grant it permissions.
     <br />
-    <strong>Revoking a key takes effect on a node only after the next deployment</strong> — driver-only
-    nodes have no config database, so keys travel inside the deployment artifact.
+    <strong>Revocation is not uniform across the fleet.</strong> A node with a config database (a fused
+    admin+driver node such as this one) applies it <em>immediately</em>, because it reads keys per
+    request. A <strong>driver-only</strong> node has no config database, so its keys travel inside the
+    deployment artifact and a revocation reaches it only on the <strong>next deployment</strong>.
+    Assume the slower behaviour when revoking a compromised key.
 </div>
 
 @if (_created is not null)