Clarify whether Ch should exist next to ReqCH and Finch

[ruslandoga]

Context

Ch predates req_ch, and both clients now cover ClickHouse-over-HTTP from Elixir. After the recent rewrite toward a smaller Mint/NimblePool-based implementation, it is worth explicitly asking whether Ch still has a clear reason to exist, or whether we are rebuilding generic HTTP pooling/client behavior that Finch/Req already handle well.

This is not meant as a conclusion that Ch should be archived. It is meant to force a sharper answer to: what does Ch bring to the table?

Current overlap

req_ch already provides a Req-native ClickHouse client for convenient HTTP querying:

• integrates with existing Req workflows;
• supports arbitrary ClickHouse formats;
• returns Req.Response;
• fits Livebook/scripts/ad hoc usage well;
• has Explorer-oriented workflows.

Finch already provides a strong general-purpose Mint/NimblePool HTTP client. If Ch is only “a ClickHouse HTTP wrapper with our own pool”, that is probably not a durable differentiator.

Questions

• Do we want Ch to compete with req_ch at all, or explicitly avoid that space?
• Is ecto_ch enough justification by itself, or should Ch have a standalone public value proposition?
• Which ClickHouse-specific pool/execution features are worth building (e.g., smarter reconnects, multihost, session multihost affinity), and which are scope creep?
• Should docs explicitly say when to use ReqCH vs Ch?