fix(jans-fido2): incomplete exception handling in Fido2RuntimeExceptionHandler impacts error reporting

Describe the bug

[Fido2RuntimeExceptionHandler.java](vscode-webview://1reblc1tfr3jcmu4ndk5asfc7846nlmid2deapa06l6m3h4j0s0o/jans-fido2/server/src/main/java/io/jans/fido2/service/handler/Fido2RuntimeExceptionHandler.java) at line 37 carries a // TODO: Finish Fido2RuntimeException exception handling marker, indicating the handler was never fully implemented. The current handleException(Fido2RuntimeException ex) method (lines 33–38) only logs the error via log.error(...) and then returns. The original implementation intent — visible in the leftover commented lines 35–36 — was to call handleExceptionInternal(ex, ex.getFormattedMessage(), new HttpHeaders(), HttpStatus.INTERNAL_SERVER_ERROR, request) and translate the runtime exception into a proper HTTP 500 response with the formatted error payload. Because that translation never happens, a Fido2RuntimeException thrown from any of the 20+ call sites in the FIDO2 server (attestation processors, MDS service, certificate service, signature verifier, assertion service, etc.) is effectively swallowed at the handler boundary: the server logs the error, but the client receives an opaque/undefined response with no structured error message, no consistent HTTP status code, and none of the rich context carried by ex.getFormattedMessage(). This is the exact "impacts error reporting" symptom flagged in the review and must be fixed before any further work builds on this handler.

To Reproduce
Steps to reproduce the behavior:

Open jans-fido2/server/src/main/java/io/jans/fido2/service/handler/Fido2RuntimeExceptionHandler.java and observe the // TODO: Finish Fido2RuntimeException exception handling on line 37, plus the dead-commented handleExceptionInternal(...) call on lines 35–36.
Trigger any FIDO2 flow that internally throws Fido2RuntimeException — for example, submit an attestation request whose certificate chain fails verification (handled in CertificateVerifier / CertificateService), or trigger MDS metadata resolution failure (MdsService / TocService).
Observe the server log: the error is captured by Fido2RuntimeExceptionHandler.handleException(...) and logged once.
Observe the HTTP response on the client side: there is no structured FIDO2 error payload derived from ex.getFormattedMessage(), and the response status / body do not reflect the standardized 500 Internal Server Error contract that the commented-out original code was meant to emit.
Expected behavior
Fido2RuntimeExceptionHandler.handleException(Fido2RuntimeException ex) should fully translate the exception into an HTTP response, in line with the other error paths in the FIDO2 server (e.g. how ErrorResponseFactory is used in AssertionController / AttestationController). Concretely, it should:

Log the error (already done) and return / propagate an HTTP 500 Internal Server Error response whose body is built from ex.getFormattedMessage() (so the client sees the same errorMessage field that's currently only being logged).
Use the project's standard error-response building blocks (ErrorResponseFactory / the structured Fido2ErrorResponseFactory payload model) rather than the older Spring-style handleExceptionInternal(... HttpHeaders ..., HttpStatus.INTERNAL_SERVER_ERROR, request) snippet that's commented out — that snippet predates the current Jakarta REST stack and is not directly portable.
Be reachable by the runtime: the class needs a CDI scope (e.g. @ApplicationScoped) so the @ExceptionHandler registration via io.jans.service.exception.ExceptionHandler actually picks it up; this should be verified as part of the fix.
Remove the // TODO: Finish Fido2RuntimeException exception handling marker and the stale commented handleExceptionInternal(...) lines once the proper implementation is in place.
After the fix, every call site that throws Fido2RuntimeException (attestation processors, MDS, cert verification, signature verification, assertion service, etc.) should produce a consistent, machine-readable error response to the FIDO2 client instead of a silent log entry.