Design reusable connection profiles and MCP-compatible export

This follows [ClickHouse/mcp-clickhouse#203](https://github.com/ClickHouse/mcp-clickhouse/issues/203). The contributor already had a named clickhouse-client profile for a remote server and wanted mcp-clickhouse to reuse it, so they wouldn't have to copy credentials into another configuration and keep both copies up to date.

I closed the request to add native Client config parsing in mcp-clickhouse after reviewing [the proposed implementation](https://github.com/ClickHouse/mcp-clickhouse/pull/204). I also considered clickcouse-connect. Either repo would have to maintain its own interpretation of clickhouse-client's configuration rules, including inheritance, includes, and environment references. The clients also use different protocols, so the native endpoint and TLS settings are not necessarily usable over HTTP.

I think the broader need might still useful though. A user should be able to define a connection once and reuse it across the CLI, MCP, and other local tools. I'd like to discuss whether clickhousectl could provide that shared connection configuration and a supported way to export it.

A useful first version could let a user:

1. Define a connection to an existing remote server, or import an existing named clickhouse-client connection. A clickhousectl-owned profile and a native-profile importer are possible approaches. I don't have a preference for the storage format at this point.
2. Provide the HTTP endpoint and TLS settings explicitly when they differ from the native connection. The selected database credentials, or references to them, would be part of that configuration.
3. Explicitly export the settings for mcp-clickhouse using the environment variables it already supports. The user's launcher would supply those values to the MCP process.

I looks like clickhousectl already has `local server dotenv` for servers it manages, but that alone doesn't cover this contributor's existing remote profile. It also needs a way to define or read that connection.

There is an existing compatibility detail to account for. In the implementations I checked, clickhousectl exports `CLICKHOUSE_PORT` as the native TCP port, while mcp-clickhouse reads it as the HTTP port. An MCP export would need to use MCP's existing meanings. More generally, the exported fields and their precedence should be documented so consumers can depend on them.

This could start with explicit export at startup. Automatic credential reload and rotation can be separate work. Cloud management credentials would also need to remain distinct from the database credentials that an HTTP client uses.

The benefit would extend beyond MCP. A supported connection format and export would give other tools a common interface to consume, reduce duplicated configuration, and avoid separate applications each trying to track clickhouse-client's config behavior. clickhousectl seems like a reasonable place to discuss that interface given its existing connection export functionality, but I'd welcome your view on whether this fits its scope.