Security: NTLM authentication uses weak DES/ECB cipher (CWE-327)

## Summary
The NTLM authentication implementation in `core/src/main/java/org/eclipse/angus/mail/auth/Ntlm.java` uses DES in ECB mode, which is considered cryptographically weak.

## Location
`core/src/main/java/org/eclipse/angus/mail/auth/Ntlm.java` — lines 104–105

```java
Cipher c = Cipher.getInstance("DES/ECB/NoPadding");
c.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(makeKey(key), "DES"));
```

## Context
This is the LM/NTLM challenge-response implementation. The DES/ECB usage is **protocol-mandated** by the NTLM specification (RFC-era design, pre-dates modern crypto). The use of ECB mode with DES 56-bit keys is inherent to NTLM v1; it cannot be changed without breaking the protocol.

## Risk
- CWE-327: Use of a Broken or Risky Cryptographic Algorithm
- NTLM credentials sent over a network can be captured and cracked offline due to the weak key derivation and ECB cipher
- Severity is limited by the fact this only applies when a server explicitly requires NTLM authentication

## Suggested action
- Add a Javadoc/comment noting that NTLM's use of DES/ECB is protocol-mandated and warn users that NTLM is a legacy protocol
- Consider emitting a log warning when NTLM auth is negotiated, advising migration to stronger auth mechanisms (e.g. OAuth2/XOAUTH2)
- Document NTLM as a deprecated/discouraged authentication method in the official docs

## Discovered by
Automated security scan (cognium-ai) of the OSS-Fuzz Java corpus, June 2026.

Start by reading core/src/main/java/org/eclipse/angus/mail/auth/Ntlm.java around lines 104–105 and the surrounding LM/NTLM challenge-response implementation. Confirm which proposed mitigation is in scope; done means the protocol-mandated DES/ECB use is clearly documented as legacy and the selected warning or official documentation update is complete.

Written by the indexing model from the issue text.