feat(jans-fido2): per-RP required User Verification enforcement

**Is your feature request related to a problem? Please describe.**
Whether User Verification (UV) is enforced during a passkey ceremony is currently decided by the client request, not by server policy, and it defaults to the weakest checking mode. In [AssertionService.options()](vscode-webview://1iavmi8q367e5lfsbh39brd12ogai0an0frq17ipifmc9b97ikhv/jans-fido2/server/src/main/java/io/jans/fido2/service/operation/AssertionService.java#L136-L138) the userVerification value is taken directly from the incoming AssertionOptions, and [CommonVerifiers.prepareUserVerification()](vscode-webview://1iavmi8q367e5lfsbh39brd12ogai0an0frq17ipifmc9b97ikhv/jans-fido2/server/src/main/java/io/jans/fido2/service/verifier/CommonVerifiers.java#L376-L382) defaults it to preferred when absent. At verification time, [UserVerificationVerifier.verifyUserVerificationOption()](vscode-webview://1iavmi8q367e5lfsbh39brd12ogai0an0frq17ipifmc9b97ikhv/jans-fido2/server/src/main/java/io/jans/fido2/service/verifier/UserVerificationVerifier.java#L43-L64) only checks the UV flag when the ceremony was required; for preferred/discouraged it merely logs.

Consequence: a relying party that must guarantee user verification cannot. A client can request userVerification: "preferred" (or omit it), the authenticator can return with the UV flag unset, and the server accepts it. There is no per-RP switch to force userVerification: "required" and reject assertions/registrations whose UV flag is not set.

BSI TR-03188 "Passkey Server" requires at the substantial level and above (SBT-1, §5.4.4) that the RP set userVerification: "required" on both create and get and verify the UV flag on the returned authenticator data. Jans should be able to enforce this per relying party.

**Describe the solution you'd like**
Add a per-RP requiredUserVerification policy field (on the RequestedParty assurance policy introduced by [#14516](https://github.com/JanssenProject/jans/issues/14516)) and enforce it end-to-end:

- **Options generation** — when the resolved policy for the RP requires UV, force userVerification: "required" in the generated assertion/attestation options regardless of what the client requested (override, don't trust the client value), and store required on the ceremony (Fido2AuthenticationData) so verification enforces it.
- **Verification** — ensure the UV flag is checked on the returned authenticator data for both assertion and attestation when the RP requires UV; reject with a clear error when the flag is unset. UserVerificationVerifier.verifyRequiredUserPresent() already implements the check — the work is making the required mode authoritative from RP policy rather than from the client-supplied option.
- **Backward compatibility** — when an RP has no requiredUserVerification policy, behavior is unchanged: the client-supplied value (default preferred) is honored exactly as today.
- Acceptance: an RP configured to require UV rejects a registration/assertion whose UV flag is unset, even if the client requested preferred/discouraged; an RP with no policy behaves exactly as today.

**Describe alternatives you've considered**

- **Change the global default from preferred to required** — `rejected`; it breaks low-friction consumer RPs and isn't per-RP, which
is the whole point (BSI expects this decision per relying party).
- **Rely on the client to send required** — `rejected`; that's the status quo and is not server-enforced, so it provides no assurance
guarantee.
- **Enforce only at verification, not in options** — `insufficient`; the generated options must also advertise required so compliant
clients prompt for UV, and so the stored ceremony option drives the verifier.

**Additional context**

- Depends on the per-RP policy anchor [#14516](https://github.com/JanssenProject/jans/issues/14516) (BSI-01) for where requiredUserVerification is stored and resolved (per-RP first,
global fallback).
- Part of the BSI TR-03188 track; this requirement maps to substantial+ (UV is required from substantial; at normal only User
Presence is mandated).
- Grounded touch points: [AssertionService](vscode-webview://1iavmi8q367e5lfsbh39brd12ogai0an0frq17ipifmc9b97ikhv/jans-
fido2/server/src/main/java/io/jans/fido2/service/operation/AssertionService.java) and AttestationService options paths,
[CommonVerifiers.prepareUserVerification](vscode-webview://1iavmi8q367e5lfsbh39brd12ogai0an0frq17ipifmc9b97ikhv/jans-
fido2/server/src/main/java/io/jans/fido2/service/verifier/CommonVerifiers.java#L376-L382), [UserVerificationVerifier](vscode-
webview://1iavmi8q367e5lfsbh39brd12ogai0an0frq17ipifmc9b97ikhv/jans-
fido2/server/src/main/java/io/jans/fido2/service/verifier/UserVerificationVerifier.java), and AssertionVerifier; confirm server-fips/
parity.
- Scope note: design/enhancement issue — no implementation until reviewed (issues-first gate).