Add per-table successful write Prometheus metrics

[millerjp]

Summary

Adds a new Prometheus counter proxy_write_success_total{cluster, keyspace, table} that tracks successful writes per cluster, per keyspace, and per table. The counter is incremented independently when each cluster responds — origin increments when origin responds, target increments when target responds.

Depends on: #163 (target consistency level override) — this PR is based on that branch.

Use case

During migration, this metric provides visibility into:

• Which tables are being written to on each cluster
• Whether both clusters are keeping up (counts should be equal)
• During a target outage, origin counters keep ticking while target flatlines — making it easy to identify which tables have diverged and need repair

Example Prometheus output

# HELP zdm_proxy_write_success_total Running total of successful writes per cluster, keyspace and table
# TYPE zdm_proxy_write_success_total counter
zdm_proxy_write_success_total{cluster="origin",keyspace="my_ks",table="users"} 148392
zdm_proxy_write_success_total{cluster="origin",keyspace="my_ks",table="events"} 52841
zdm_proxy_write_success_total{cluster="origin",keyspace="my_ks",table="audit_log"} 7203
zdm_proxy_write_success_total{cluster="target",keyspace="my_ks",table="users"} 148392
zdm_proxy_write_success_total{cluster="target",keyspace="my_ks",table="events"} 52841
zdm_proxy_write_success_total{cluster="target",keyspace="my_ks",table="audit_log"} 7203

During a target outage, the target counters stop incrementing while origin continues:

zdm_proxy_write_success_total{cluster="origin",keyspace="my_ks",table="users"} 162504
zdm_proxy_write_success_total{cluster="target",keyspace="my_ks",table="users"} 148392

The difference (14,112) tells you exactly how many writes to my_ks.users the target missed.

Implementation

• WriteTarget type carries keyspace/table through the request lifecycle
• GetWriteTargets() on RequestInfo interface, populated at parse time
• For inline queries: extracted from ANTLR parse result
• For prepared statements: stored on PrepareRequestInfo during PREPARE, accessed via PreparedData cache at EXECUTE time
• For batch statements: per-child table extraction for both inline and prepared children, with deduplication
• Counter cache on MetricHandler with double-checked locking (same pattern as per-node metrics)

Test plan

• Unit tests for metric counter creation, caching, and concurrent access
• CCM integration tests covering full permutation matrix:
  • Inline: INSERT, UPDATE, DELETE, counter UPDATE
  • Prepared: INSERT, UPDATE, DELETE, counter UPDATE
  • Batch inline: multi-table, update+delete
  • Batch prepared: multi-table, update+delete
  • Batch mixed: inline + prepared children
  • Counter batch: inline and prepared
  • Data verification on both clusters
• All existing unit tests updated and passing

Resolves #165