feat(metrics): RocksDB write-stall gauges

[mo4islona]

Why

The post-deploy ingest freeze (all datasets freeze ~6 min, then resume together) looks like a global RocksDB write-stall on the shared Arc<Database>: RocksDB keeps one WriteController per DB, so a stall triggered by any single column family throttles writes DB-wide → every dataset freezes at once, releasing when compaction catches up. Retrospective telemetry can't show it — RocksDB's own stall state was never exported.

What

hotblocks_rocksdb_* gauges via a pull-collector (RocksDbCollector). Reads intrinsic RocksDB properties on scrape only — no write-path cost, no enable_statistics() needed:

• DB-wide: write_stopped (decisive), actual_delayed_write_rate, running_compactions, running_flushes
• per-cf (CHUNKS, TABLES): num_files_at_level0, estimate_pending_compaction_bytes, num_immutable_mem_table, mem_table_flush_pending

Plus Database::get_int_property + a test pinning the property names (a typo → silent None → missing gauge).

Verifying the freeze

On the next deploy/freeze, hotblocks_rocksdb_write_stopped == 1 plus a spike in num_files_at_level0 / estimate_pending_compaction_bytes confirms a write-stall and names the trigger. The existing --rocksdb-max-background-jobs flag is the lever to raise background jobs if the autodetected 2..=8 default is too low.

🤖 Generated with Claude Code

[mo4islona]

Closing — the --rocksdb-max-background-jobs flag already ships on master (#79), so bumping background jobs needs no code: just run the pod with --rocksdb-max-background-jobs 8. The RocksDB write-stall metrics from this branch aren't needed right now; can revisit separately.