Observability: add cache-hit instrumentation to createCapabilitiesPayloadProvider

[coderabbitai]

Summary

The capabilities payload cache in src/admin/capabilities.ts was changed from eager to lazy initialisation (PR #7). No cache-hit metric or structured log event was added alongside this change, so the cache-hit rate is currently unmeasurable in production.

Required work

Add a cache-hit counter or frequency metric to createCapabilitiesPayloadProvider. Emit a structured log event on each cache hit, following the bounded-cardinality, stable-reason-code observability conventions already established in the codebase. A suitable event shape is:

{ "event": "digitalpuddle.admin.capabilities.cache_hit" }

Alternatively, instrument via a dedicated metrics facade if one is introduced. The implementation must not reintroduce PII or high-cardinality fields into the log payload.

Acceptance criteria

• A structured log event is emitted on every cache hit (i.e., every invocation of the provider after the first).
• The event uses a stable, bounded-cardinality reason code (e.g., digitalpuddle.admin.capabilities.cache_hit).
• A unit test in tests/base.test.ts verifies the log event is emitted on the second and subsequent invocations of a provider instance, but not on the first.

Context

• Raised during review of PR Introduce target source layout incrementally (1.2.2) #7 (1-2-2-introduce-target-source-layout-incrementally)
• Requested by @leynos
• Related file: src/admin/capabilities.ts