feat(admin-ui): Add Auth Metrics dashboard for authentication and token activity

# Auth Metrics Dashboard in Admin UI

## Description
The auth server records authentication and token activity through its metric reporter, but none of it is visible in the Admin UI. There is currently no way to see authentication volume, success and failure rates, which ACRs are in use, or how many tokens are issued, without querying the `jansMetric` store directly.

This adds an **Auth Metrics** screen under the FIDO section, reading the metric plugin's `/metric/entries` endpoint.

## Goals
- Add an Auth Metrics screen with a KPI strip and three charts, reusing the existing dashboard components and theme so it matches the Passkey Security Monitor.
- Reuse the MAU `DateRangeSelector` rather than building a second date filter.
- Offer bucket sizes that suit the selected range, so no combination produces an unreadable chart.
- Read every row in the range, so totals are never silently truncated.

## Requirements / Details

**Data** — six series from `GET /metric/entries`: `user_authentication_success`, `user_authentication_failure`, `tkn_access_token_count`, `tkn_id_token_count`, `tkn_refresh_token_count`, `tkn_authorization_code_count`. `metric-plugin-swagger.yaml` is added to `openapi-merge.json` so the client is generated by orval.

**Screens**
- KPI strip: Attempts, Successful, Failed, Auth Success Rate, ACRs in use
- Authentication Activity: successful vs failed over time
- Authentications by ACR: successes split by `jansMetricSubTyp`
- Token Issuance: access, ID and refresh tokens, plus authorization codes

**Filtering** — presets of 24 Hours / 7 Days / 30 Days plus manual dates, both ends snapped to day boundaries. Granularity is a menu under the chosen preset, with options derived from the span of the range:

| Range | Buckets |
|---|---|
| up to 2 days | Hourly, 3 Hours, 12 Hours, 24 Hours |
| up to 14 days | Daily, 3 Days, 7 Days |
| over 14 days | Daily, 3 Days, 7 Days, 15 Days, 21 Days, 30 Days |

The widest bucket in each tier spans the whole range, giving the range total in one point.

**Notes**
- `/metric/aggregations` is not used: its producer task is not deployed and it returns an empty page. Bucketing is therefore client-side, and every page of `/metric/entries` must be walked (a 7-day window is ~2,000 rows per metric type against a 500-row page).
- With `subType` omitted the endpoint returns both plain and per-subtype rows for the same window, so charts must pick one to avoid double counting.
- The metric endpoints work entirely in UTC, so dates are sent without an offset and buckets break on UTC boundaries.

## Known limitations
- No latency metric exists in the auth server's `MetricType` enum.
- Retention follows `metricReporterKeepDataDays` (15 days on test deployments), so the 30-day preset returns at most 15 days.
- If the `/metric/aggregations` producer ships, coarse buckets should move server-side, removing the need to page.