fix(opcua): credential lockout review fixes (#833)

- Reserve an in-flight slot per client before authenticating (TryBegin /
  Complete / Abandon under one lock); refuse once recorded failures +
  in-flight attempts reach MaxFailedAttempts, so a parallel burst cannot
  pass the check before its first failure is recorded.
- An expired lockout resets the count (LockoutSeconds < FailureWindowSeconds
  relocked on every single failure after the first lockout).
- Validate OpcUa:CredentialLockout at host start: disabled, or both
  durations > 0.
- Log the first refusal of a lockout episode at Information, the rest at
  Debug.
- Document that on None endpoints the key is effectively IP-only (NAT
  neighbours share a UserName count) and a null peer shares one key.

docs/Configuration.md

@@ -75,8 +75,8 @@ Until #678.6 the overlay never loaded on a node carrying a `cluster-*` role (the
 | `AutoAcceptUntrustedClientCertificates` | bool | `false` | Auto-trust unknown client certs on first connect (dev convenience). Not validated. See [`security.md`](security.md). |
 | `PeerApplicationUris` | list of string | `[]` (empty) | Partner node `ApplicationUri`s published in `Server.ServerArray` for redundancy discovery. See [`Redundancy.md`](Redundancy.md). |
 | `CredentialLockout:MaxFailedAttempts` | int | `5` | Failed UserName (API-key) activations from one client before its UserName activations are refused `BadUserAccessDenied` (#833). `≤ 0` disables. **Never refuses Anonymous.** See [`security.md`](security.md#failed-credential-lockout-opcuacredentiallockout). |
-| `CredentialLockout:FailureWindowSeconds` | int | `60` | A failure more than this long after the client's previous one starts a fresh count. |
-| `CredentialLockout:LockoutSeconds` | int | `300` | How long a locked-out client's UserName activations are refused. |
+| `CredentialLockout:FailureWindowSeconds` | int | `60` | A failure more than this long after the client's previous one starts a fresh count. Must be `> 0` while the lockout is enabled (validated). |
+| `CredentialLockout:LockoutSeconds` | int | `300` | How long a locked-out client's UserName activations are refused; an expired lockout starts a fresh count. Must be `> 0` while the lockout is enabled (validated). |
 
 > **Transport security profiles** (the values in `EnabledSecurityProfiles` — `None`, `Basic256Sha256Sign`, `Basic256Sha256SignAndEncrypt`) and the PKI trust flow are documented in full in [`security.md`](security.md). This page does not duplicate them.
 

docs/security.md

@@ -334,10 +334,23 @@ The host now sets `MaxFailedAuthenticationAttempts = 0` on every configuration i
 - **UserName activations only.** A failed one counts; at `MaxFailedAttempts` (5) within
   `FailureWindowSeconds` (60) of each other, that client's **UserName** activations are refused
   `BadUserAccessDenied` for `LockoutSeconds` (300) without the key store being consulted, and a Warning is
-  logged once. A refusal during the lockout is not counted (it never extends itself); a successful UserName
-  activation clears the count. **Anonymous activations never consult it**, from any client.
-- **Keyed on certificate thumbprint *and* peer address together**, so locking a client out needs both its
-  certificate and its source address, and NAT neighbours with different certificates do not share a count.
+  logged once. A refusal during the lockout is not counted (it never extends itself); an **expired lockout
+  always starts a fresh count**, whatever `FailureWindowSeconds` is; a successful UserName activation clears the
+  count. **Anonymous activations never consult it**, from any client. The first refusal of each lockout episode
+  is logged at Information, the rest at Debug.
+- **Parallel activations are held to the threshold.** The check reserves an in-flight slot under the same lock,
+  and a client whose recorded failures plus in-progress UserName activations already reach
+  `MaxFailedAttempts` is refused (`BadUserAccessDenied`, "too many authentication attempts in progress"), so a
+  burst cannot slip past the check before its first failure is recorded. ⚠️ The same rule caps a **legitimate**
+  client at `MaxFailedAttempts` concurrent UserName activations (the check is milliseconds, so this only bites a
+  burst of simultaneous session opens from one key).
+- **Keyed on certificate thumbprint *and* peer address together.** That separates clients only when they present
+  a certificate. ⚠️ On a `None` endpoint clients commonly present none, so the key is **effectively the IP alone**:
+  NAT neighbours there **do** share one count (for UserName activations only — never for anonymous ones). When the
+  transport reports no peer address at all, every certificate-less client shares the single key `-@-`. (Observed on
+  docker-dev: every host client arrives as `-@192.168.97.1`.)
+- **Validated at host start:** with `MaxFailedAttempts > 0`, both `LockoutSeconds` and `FailureWindowSeconds` must be
+  `> 0` (`OpcUaApplicationHostOptionsValidator`); `MaxFailedAttempts <= 0` disables the lockout.
 - Every denial counts, including a key-store timeout or miss-budget refusal (as the SDK's did) — a ConfigDb
   outage can therefore lock a keyed client out for up to `LockoutSeconds` after recovery.
 - Bounded at 4096 tracked clients (expired entries are pruned; a client arriving at a full table is not