winrm-light 2/6: NTLM message encryption over HTTP (port encryption streams off CXF)

[bertysentry]

Depends on #103.

WinRM over plain HTTP (5985, the common configuration) requires SPNEGO/NTLM session encryption: SOAP bodies sealed with RC4 keys derived from the NTLM session key, wrapped in multipart/encrypted with signed sequence numbers.

Scope

• Port the existing, battle-tested logic in org.metricshub.winrm.service.client.encryption (EncryptAndSignOutputStream, DecryptAndVerifyInInterceptor, NtlmKeys, MD4, ...) from CXF interceptors/conduits to plain request/response stream wrappers in the light client. The crypto is already framework-agnostic; only the plumbing changes.
• Key handoff from the NTLM authenticator (winrm-light 1/6: Framework-free WSMan core (templated envelopes, JDK HTTP, NTLM over HTTPS) #103) to the sealing layer.
• Careful sequence-number handling across retries on the affine connection.

Acceptance

• WQL + command execution against a real host over HTTP/5985 with NTLM (AllowUnencrypted=false, the Windows default) — byte-compatible with what the CXF stack negotiates today.

🤖 Generated with Claude Code

[bertysentry]

Delivered in #109 (branch `feature/winrm-light`). NTLM message encryption over plain HTTP is in `NtlmCrypto` (RC4 seal/sign + unseal/verify, `multipart/encrypted` framing, signed sequence numbers), ported from the existing `org.metricshub.winrm.service.client.encryption` logic with the CXF/Apache coupling stripped. Root-cause fix baked in: the NTLM domain must be uppercased before NTOWFv2 or the server-side seal mismatches (HTTP 400). Live-verified WQL + command over HTTP/5985 with `AllowUnencrypted=false` (the Windows default). Subsequent review rounds hardened it (reject unencrypted responses after auth, serialize the connection, stale-connection detection, US-ASCII protocol constants).

🤖 Generated with Claude Code