Add a pdv_monitoring submodule integrating the monitoring module

Summary

Add an optional pdv_monitoring submodule that exposes pdv operational health as monitoring module sensors, for continuous checks, thresholds, and external alerting. It depends on the contrib monitoring module; core pdv stays dependency-free, mirroring the audit bridge pattern. It complements the dependency-free Status Report health checks in #3593592: Add a health surface via hook_requirements (Status Report) by adding trends, thresholds, and external integration.

Sensors

• Master KEK reachable and valid (CRITICAL): the configured Master KEK resolves, the backend (key module or OpenBao) is up, and the key is 32 bytes. The vault cannot seal or unseal without it.
• Seal/unseal failure rate: the rate of KekException and DecryptionException, surfaced through the watchdog-severity sensor or a dedicated counter; a spike means key or backend trouble, or tampering.
• Grant-request backlog and GC freshness: the count of open pdv_grant_request rows, the age of the oldest, and whether the GarbageCollector sweep keeps expired rows bounded.
• Master KEK rotation progress: the number of subjects still wrapped under an old Master KEK after a rotation (MasterKeyRotator state).
• Consumer flood and failed consent/grant attempts: from ConsumerFloodGuard; a spike is an abuse signal.
• Cross-site consumer auth failures: failed token auth on the server API (RemoteVaultClient consumers) as a security signal.

Design notes

• Optional submodule depending on the monitoring contrib module; no new dependency on core pdv. Same pattern as the audit_trail bridge submodules.
• Reuse the same underlying checks as the Status Report requirements in the companion issue where they overlap (KEK, storage, backlog), so the two surfaces do not drift.
• No PII, no key material, and no user identifiers in any sensor value or message; aggregates and counts only. Sensor output reaches logs and external systems.
• Distinct from audit_trail: monitoring is operational health ("is the system healthy"); audit_trail is the compliance event stream ("who did what"). Do not route audit events through sensors or the reverse.
• Confirm the monitoring module Drupal 11 compatibility before committing the dependency.

Tests

• Each sensor returns OK under normal conditions and the expected status when its condition trips (missing KEK to CRITICAL, backlog over threshold to WARNING, and so on).
• Sensor values and messages contain no uid, key bytes, or document content.