Address RAMPART-427 review: document init trade-off, guard config parsing

Follow-up to the Gemini review of the RAMPART-427 fix (both findings are
pre-existing in RampartMessageData, not introduced by the race fix):

- Document the performance-vs-correctness trade-off of running the WSS4J /
  Santuario / OpenSAML one-time initialisers in the per-message constructor: the
  calls are idempotent guards kept there to avoid the OpenSAML-5-migration
  unmarshallerFactory ordering bug; moving them to a once-per-lifecycle init is a
  separate, riskier change. No behaviour change.
- Wrap the timestampTTL / timestampMaxSkew Integer.parseInt calls so a non-numeric
  RampartConfig value throws a clear RampartException naming the offending
  parameter and value, instead of an unhandled NumberFormatException. Adds the
  invalidRampartConfigValue message.

(The reviewer's third, JUnit-version, note is skipped to stay consistent with the
existing test suite style.) Verified with a full clean -Papache-release verify
across all modules including the nine policy samples on JDK 25.

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