fix(opcua-client): send UserName passwords in the legacy RSA format so 65-char API keys log in to SDK 1.5 servers (#880)

SDK 2.0.1's UserNameIdentityTokenHandler encrypts a password longer than 64 bytes
(a private RsaEncryptedSecretPasswordThreshold, no setting) as an RsaEncryptedSecret
with EncryptionAlgorithm=null. SDK 1.5.378 (.106 and .182) decrypts only the legacy
format under RSA policies; its SecurityPolicies.Decrypt answers a null algorithm with
BadIdentityTokenInvalid ("Unexpected encryption algorithm") before any key check.
Every production API key is 65 chars, so no SDK 2 OtOpcUa client could use one
against QA (b8b4c18f), a rollback target or an older third-party server.

LegacyRsaUserNameIdentityTokenHandler (Driver.OpcUaClient.Session, plugged in through
the public UserIdentity(IUserIdentityTokenHandler) ctor) always uses the legacy
format, RSA-OAEP(len|password|serverNonce) under the server certificate, under an RSA
policy. That is what SDK 2 sends for passwords of 64 bytes or less and what SDK 1.5
clients always send. The legacy format has no size limit (the plaintext is
length-framed over as many RSA blocks as it needs), and an SDK 2 server reads both
formats. Policy None, the ECC policies and a missing certificate go to the SDK
handler unchanged.

OpcUaUserIdentityFactory.UserName is now the one UserName identity the driver, the
AdminUI browse and Client.Shared (CLI/UI) present. Client.Shared references .Session
for it.

Tests: handler unit tests (all three RSA policies, the 1.5-required algorithm URI,
SDK 2 server-side decrypt, the session Copy() keeps the type, None unchanged, and an
SDK control pinning the 64/65-byte switch); a Client.Shared identity test; and an
SDK2<->SDK2 integration test where a 65-char key is admitted in both formats and a
wrong 65-char key reaches the key check (BadIdentityTokenRejected). The #800 Windows
gate's SDK 2 CLI 65-char case now gates against the 1.5 server too.

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

docs/plans/2026-11-10-opcua-sdk-2-rollout.md

@@ -338,6 +338,12 @@ thresholds or count absent environments as passed.
    Rebind namespaces by URI. Never replay ambiguous non-idempotent writes or alarm
    acknowledgements. Confirm API-key writes/ack, subscriptions, alarm counts and history
    continuity with the same positive and negative checks used at rollout.
+   **Tooling against a rolled-back (SDK 1.5) node (#880):** an SDK 2 client logs in to
+   it with a 65-character API key only if it forces the legacy UserName password
+   format. The OtOpcUa CLI/UI, the OpcUaClient driver and the AdminUI browse do so from
+   the #880 fix onward, but SDK 2 builds older than that fix are refused with
+   `BadIdentityTokenInvalid`. Generic SDK 2 tools that use the SDK's default UserName
+   handler are refused the same way. Use SDK 1.5 tooling or a post-fix CLI.
 5. Record recovery time, checks, data reconciliation and final hold/go decision.
    If rolling source back, revert package and application commits together; never
    mix old package binaries with SDK 2 application assemblies. Keep candidate evidence