Wire up OpenTelemetry (traces + metrics) for the core service

[vectorloom]

ARCHITECTURE.md already documented OpenTelemetry as the intended observability approach; it was never actually wired in (README was recently corrected to say so after a grep found zero references to it anywhere in the codebase). This closes that gap.

• ASP.NET Core auto-instrumentation for both traces and metrics.
• OTLP exporter added only when OTEL_EXPORTER_OTLP_ENDPOINT is set (read through IConfiguration, same as EnvironmentSecretProvider) -- a self-hoster who sets nothing gets no attempted exports. Verified both states directly: ran the service with the env var unset and confirmed clean logs across a request cycle, then with it pointed at a throwaway local HTTP listener and OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf, confirmed real POST /v1/metrics and /v1/traces requests arriving on the configured export interval. First attempt (before forcing the protocol) came in as HTTP/2 and failed against the plain HTTP/1.1 listener, confirming gRPC is the SDK's actual default -- switchable via the same standard env var, no RiftCache-specific config needed.
• New CacheMetrics: hit/miss counters + a live entry-count gauge via System.Diagnostics.Metrics, which the OTel SDK picks up once CacheMetrics.MeterName is registered with .AddMeter(...).
• New MeteredCacheStore, an ICacheStore decorator recording hits/misses around GetAsync. Decorator rather than injecting CacheMetrics directly into InMemoryCacheStore: CacheMetrics depends on InMemoryCacheStore for the gauge, so the reverse dependency would be circular. CacheEvictionService keeps injecting the concrete InMemoryCacheStore directly and is unaffected.
• Tests use MeterListener filtered by exact Meter instance (CacheMetrics now exposes it internally) rather than just MeterName, since multiple tests create their own CacheMetrics with the same meter name and xUnit can run different test classes in parallel -- name-only filtering would leak measurements across tests.

README/ROADMAP updates deliberately left out of this PR: they'd describe both this and the still-unmerged http-client-resilience PR as done, and I don't control merge order. Following up once both are confirmed merged into main.