feat(jans-fido2): extend FIDO2 metrics with mobile dimensions and internal diagnostic codes

**Is your feature request related to a problem? Please describe.**
Success/failure rates alone don't reveal *why* native rollouts fail. Operators need to see failures clustered by platform, app version, Android signing key, Play Services version, OEM, native API (Credential Manager / ASAuthorization / legacy / WebView), origin-policy result, and post-install timing. The metrics subsystem already exists and is the right home — `Fido2MetricsEntry` carries `errorReason`/`errorCategory`/`fallbackMethod`/`fallbackReason`, `DeviceInfoExtractor` tags OS/device-type, and `Fido2MetricsController` exposes analytics (`/analytics/errors`, `/analytics/devices`, …). But those dimensions are browser-shaped and don't include native context, and there are no internal diagnostic codes for native failure modes.

**Describe the solution you'd like**
- **Extend the existing metrics** (do not build a new subsystem) with mobile dimensions sourced from the client telemetry envelope: `platform`, `os_version`, `app_version`, `device_manufacturer`, `native_api`, `origin_policy_result`, `aasa_status`/`assetlinks_status`, `flow_context`, plus derived measures like fallback rate by platform/app-version and "first-24h-after-install" failure rate. Add them to `Fido2MetricsEntry`/`Fido2MetricsData` and to the analytics groupings.
- **Introduce internal diagnostic codes** populated into the existing `errorReason`/`errorCategory` fields (additive — no new store), e.g. `JFS_NATIVE_ORIGIN_NOT_ALLOWED`, `JFS_ANDROID_APK_HASH_ORIGIN_UNCONFIGURED`, `JFS_ASSETLINKS_PLAY_KEY_MISMATCH`, `JFS_AASA_NOT_READY_AFTER_INSTALL`, `JFS_RPID_HASH_MISMATCH`, `JFS_DEVICE_NOT_SECURE`, `JFS_USER_CANCELLED_SYSTEM_SHEET`, `JFS_WEBVIEW_UNSUPPORTED_ORIGIN`.
- **Keep the public FIDO response envelope unchanged** — `ErrorResponseFactory`/`Fido2ErrorResponse` still return `{status:"failed", errorMessage:"…"}`; the diagnostic code goes to metrics/structured logs (with `client_correlation_id`), never the client body.

**Describe alternatives you've considered**
- *A new mobile-metrics subsystem* — rejected; duplicates the existing one and its aggregation/analytics pipeline.
- *Put diagnostic codes in the client response* — rejected; would break FIDO conformance envelope expectations and leak internal detail.

**Additional context**
Depends on the client telemetry envelope for the richer dimensions; the mobile origin/RP-ID policy model supplies `origin_policy_result`. Update `docs/METRICS_WIKI.md` with the new dimensions.
Corbado article — https://www.corbado.com/blog/native-ios-android-passkey-implementation-challenges ;
ChatGPT analysis — https://chatgpt.com/share/6a5129bc-a8f4-83ea-8649-3e463e0a7db3