feat(metrics): export KV counters and populate the tiered-log family (#44)

[oreofeolurin]

The last two families from #44. Closes it.

The decision the issue asked for

Export, not delete. Per-namespace KV operation rates and hot/warm hit rates are exactly what you need to size a hot buffer or notice a workload shift — deleting them would remove the observability, not the dead code problem.

KV — recorded nowhere, and never emitted

Two separate gaps. recordGet/recordSet/recordDelete had no callers, and exportPrometheus had no KV branch at all — so unlike the other families, the series didn't exist rather than reading 0.

Added writeKVMetrics plus the export loop, and wired the three record calls into the KV dispatch paths using the per-namespace metrics that registerKVNamespace already returned and the code discarded.

Tiered log — written but never registered

The opposite shape: writeTieredLogMetrics was already called by exportPrometheus, but registerTieredLog had zero callers, so no entry ever existed to iterate over.

The shard now registers its log once at wire-up and hands the pointer to the stream handler. getPayloadAndTier already decides hot vs warm per record, so recording there costs nothing extra — and resolving the pointer at wire-up keeps a registry lookup off the read path.

if (self.partition.ual.read(ual_index)) |ual_entry| { ... tm.recordHotHit(); }
if (self.partition.readPayloadWarm(ual_index)) |raw| { ... tm.recordWarmHit(); }
tm.recordMiss();

cold_hits stays 0 by design — that path consults the hot ring and warm store only, never cold. Left visible rather than faked, since a fabricated number is the exact problem this issue is about.

Tests

Two more value-asserting e2e tests: two sets, a get and a delete produce 2/1/1 on the KV counters; an append plus read produces a non-zero hot-hit count. Both fail with the instrumentation stashed.

test-unit, test-integration, e2e/kv and e2e/stream all pass — the 4 kv/cluster failures are the pre-existing set from #62.