feat(jans-fido2): add unit tests for Fido2MetricType enum

**Is your feature request related to a problem? Please describe.**

The FIDO2 metrics feature added several model classes under `jans-fido2/model/src/main/java/io/jans/fido2/model/metric/`, but the model module has no tests for them. `Fido2MetricType` exposes metric name strings that are persisted and used as DB attribute values — if any of them silently change, downstream aggregation/queries break and we have no test to catch it. This is the first step of a larger effort to add comprehensive test coverage for the FIDO2 metrics functionality, starting from the smallest, dependency-free pieces.

**Describe the solution you'd like**

Add a new JUnit 5 test class:

- File: `jans-fido2/model/src/test/java/io/jans/fido2/model/metric/Fido2MetricTypeTest.java`

The test should cover:
- `getMetricName()` returns the expected string for every enum value (10 values: `FIDO2_REGISTRATION_ATTEMPT`, `FIDO2_REGISTRATION_SUCCESS`, `FIDO2_REGISTRATION_FAILURE`, `FIDO2_REGISTRATION_DURATION`, `FIDO2_AUTHENTICATION_ATTEMPT`, `FIDO2_AUTHENTICATION_SUCCESS`, `FIDO2_AUTHENTICATION_FAILURE`, `FIDO2_AUTHENTICATION_DURATION`, `FIDO2_FALLBACK_EVENT`, `FIDO2_DEVICE_TYPE_USAGE`).
- `getDescription()` returns a non-null, non-empty string for every value.
- `toString()` returns the metric name (it overrides the default `Enum.toString()`).
- `Fido2MetricType.values().length == 10` — guards against accidental additions/removals that would break consumers relying on a fixed set.

Conventions to follow (from existing test `jans-fido2/server/src/test/java/io/jans/fido2/service/shared/MetricServiceTest.java`):
- JUnit 5 (`org.junit.jupiter.api`)
- No Mockito needed — pure value test, no dependencies
- One `@Test` method per behavior, named `testXxx`

Acceptance criteria:
- [ ] New test file exists at the path above.
- [ ] All four behaviors listed are covered.
- [ ] `mvn -pl jans-fido2/model test` passes locally.
- [ ] No changes to production code under `src/main`.

**Describe alternatives you've considered**

- Skipping this and starting with a larger service (e.g. `Fido2MetricsService`). Rejected because that class is 1133 lines with persistence and async dependencies, and there is no existing test infrastructure under the `model` submodule yet — starting tiny establishes the pattern and lets follow-up issues build on it.
- Bundling enum + constants + DTO tests into one issue. Rejected to keep the issue genuinely small and reviewable in minutes.

**Additional context**

This is issue 1 of a planned series to cover the FIDO2 metrics surface area. Planned follow-ups (each as its own small issue):

1. **(this issue)** `Fido2MetricType` enum
2. `Fido2MetricsConstants` constants
3. `Fido2MetricsData` DTO
4. `UserMetricsUpdateRequest` DTO
5. `Fido2UserMetrics.calculateUserRiskScore()` logic
6. Strengthen existing `MetricServiceTest` (replace `assertDoesNotThrow` smoke checks with real `verify()`/argument-captor assertions)
7. `Fido2MetricsService` — split across multiple issues (store, query, aggregate, analytics)
8. `Fido2UserMetricsService`
9. `Fido2AnalyticsService`
10. `Fido2MetricsAggregationScheduler`
11. `Fido2MetricsController` endpoints