feat(jans-fido2): define monitor vs enforced attestation-mode semantics

@imran-ishaq is already working on this.

Since Jun 17, 2026.

In jans-fido2, attestation has three modes: `disabled`, `monitor`, and `enforced`. Today `monitor` and `enforced` behave almost identically — both run the full attestation validation and reject on failure; only `disabled` skips validation. Currently in jans-fido2 the default mode is `monitor` (`Fido2Configuration.attestationMode = "monitor"`).

The FIDO2 conformance work (tracking issue [#9640](https://github.com/JanssenProject/jans/issues/9640)) expects `monitor` to be lenient — i.e., validate and log problems, but still allow the registration — while `enforced` rejects.

So making `monitor` lenient would change the security behavior of default deployments — they would start accepting attestations they currently reject. Because this weakens the out-of-the-box security posture, it needs a product decision before we write any code.

1. Should `monitor` (the default) actually become permissive, or should the default be changed to enforced so existing deployments stay strict?
2. Should leniency apply only to metadata / attestation-trust failures (e.g. MDS lookup, certificate chain) and never to core cryptographic checks (signature, challenge, RP-ID)? (Recommended — we should never skip crypto, eveN in monitor.)
3. When a monitored attestation "fails but is allowed," how should we still populate the registration data (credential ID / public key) so the registration completes cleanly?

**Describe alternatives you've considered**
- Leave `monitor` strict (current behavior) and just document the distinction — safest, no regression, but doesn't meet the conformance expectation.
- A blanket "catch all failures and allow" in the attestation path — rejected: it would also swallow genuine cryptographic failures and would leave registration data incomplete.

**Additional context**
Part of the FIDO2 conformance effort (#9640). The narrow, safe part of this distinction is already implemented separately (in `enforced` mode an MDS metadata-fetch failure now rejects, while `monitor`/`disabled` fall back to today's behavior). This issue is specifically about the broader mode-semantics decision above. It's probably best finalized once we're actually running the FIDO conformance test tool, so we can confirm exactly which failures `monitor` is expected to tolerate.