feat: add support for multiple labeled clickhouse read clusters

[amokan]

Why?

Every ClickHouse query currently lands on a single cluster, so a heavy workload such as dashboard log scans or a burst of MCP/agent queries can potentially starve resources away from competing queries.

This change allows multiple read-only clusters to be configured for a backend and queries to be routed using an optional LF-ENDPOINT-CLICKHOUSE-READ-CLUSTER-LABEL header provided to an endpoint, similar to the existing LF-ENDPOINT-BIGQUERY-RESERVATION header. Ultimately allowing us to isolate certain classes of queries to their own backing read clusters.

Key Changes

• ClickHouse backends can now define multiple labeled read clusters via a read_only_urls config option as well as a default_read_cluster label to fall back to.
• The adaptor reads the header into opts[:read_cluster] and selects a per-label read pool, running one supervised ConnectionManager and pool per {backend, label}. This follows the existing BigQuery reservation header → opts → adaptor path.
• Resolution degrades gracefully so an unknown or absent label falls back to the default cluster (or a legacy read URL when nothing is configured). An unhealthy labeled pool retries once on the default. With no header and no read_only_urls config, behavior is identical to today, so this is a no-op until a backend has opted in to this feature.
• Updates the backend-form LV to handle the multiple read only cluster/label situation.

Additional Notes

• The existing read_only_url config option will be removed in a later PR

[Ziinc]

the config handling of read_cluster_url feels like a code smell, doesn't integrate very well with the label mapping system (which i'm fine with)

[Ziinc]

still needs the header tweak