Endpoints for every ClickHouse version

Originally posted by @alexey-milovidov: Endpoints for every ClickHouse version

Implement endpoints like

```
v24.3.fiddle.clickhouse.com
pr65432.fiddle.clickhouse.com
```
They will be backed by a single server in AWS with a large EBS volume to hold the binaries.

The endpoints will only support the HTTP interface.
Only the latest patch version for every minor version is supported.

The traffic will be routed by a CloudFlare worker and a wildcard DNS record.

The worker will use a simple logic to map the subdomain to a port number. For example, v24.3 will be mapped to port 2403, and pr65432 will be mapped to 15432 where 1 is fixed, and 5432 is the remainder of the division of PR number by 10000. It will attempt to request on the specified port. If the port is not available, it will instead make an API request to a controller service, running on that server at port 8080. The controller service will receive a request to run a certain clickhouse-server version, make this request synchronously, and return a reply when the server is available. Then, the worker will repeat the previous request.

ClickHouse will be downloaded as a single binary to a subdirectory and run without installation.

The server should not use Docker, Kubernetes, ECR, Lambda, or other hi-tech.

It is expected that the service will often be broken or that it could be abused.

The goal is to provide a tool for reviewers to quickly try the features, or a component for AI to facilitate testing, or a honeypot to find bugs.

Start by locating the Go service entry points and understand how the existing ClickHouse playground is served. Then map the requested CloudFlare worker, wildcard DNS, AWS server, port-based routing, and controller on port 8080; done means version and PR endpoints can launch the requested ClickHouse binary and serve its HTTP interface.

Written by the indexing model from the issue text.