RAMPART-44 / RAMPART-252: enforce the policy algorithm suite on inbound messages

Rampart did not check that the algorithms actually used in an incoming message
matched the policy's algorithm suite, so a peer could downgrade to weaker
signature / digest / canonicalization / encryption / key-wrap algorithms and the
message would still be accepted (RAMPART-44).

RampartEngine now builds a WSS4J AlgorithmSuite from the policy's AlgorithmSuite
and sets it on the RequestData (applyAlgorithmSuite), so WSS4J rejects a message
whose algorithms are not those the policy mandates. Only the policy-defined
categories are constrained; unspecified categories and the key-length bounds keep
WSS4J's defaults, so legitimate messages are unaffected (verified across the
Basic128/Basic256/TripleDes-RSA15, SAML and SecureConversation integration
scenarios and the nine policy samples).

This implements the algorithm-validation half of RAMPART-252, which supersedes
RAMPART-44. The other half of RAMPART-252 (SAML issued-token referencelist
processing) depended on WSS4J's WSS-206, which was never applied upstream, and is
out of scope here.

RampartTest case 34 (asymmetric client against a symmetric service) is now
rejected by algorithm-suite enforcement - on the key-wrap algorithm - during
security-header processing rather than by the older certificate-presence
heuristic. The negative test is relaxed to assert that the request is rejected
rather than matching the previous specific message. Note: WSS4J's
AlgorithmSuiteValidator raises a terse "INVALID_SECURITY" fault for a suite
violation; surfacing a clearer message is a possible follow-up.

Verified with a full clean -Papache-release verify on JDK 25.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>