Mirror release archives to S3 from the release workflow

[sdairs]

Problem

A new clickhousectl release can be advertised before its downloadable archives exist on builds.clickhouse.com. The CLI discovers new versions through GitHub Releases (including its background update notice), but clickhousectl update, the quick-install script, npm installation, and cargo-binstall download from the builds mirror. During the gap, users see an available update and then hit a missing download.

Today the main ClickHouse repository's NightlyUpload workflow runs daily at 06:13 UTC. Its Upload clickhousectl job discovers the latest GitHub release, copies missing assets to s3://clickhouse-builds/clickhousectl/, and skips objects already present. Most runs do nothing; a new release can wait until the next daily run.

Move ownership of that mirroring into this repository's release workflow so the same release run uploads and verifies the assets immediately. This is a scoped onboarding task for a new CLI engineer; the owner will select the assignee.

Existing implementation and consumers

• Generated upstream NightlyUpload workflow.
• Upstream workflow source and actual upload job.
• This repository's release workflow.
• Consumers: CLI updater, quick installer, npm installer, and cargo-binstall metadata.

The current contract is four .tar.gz archives, one each for x86_64-unknown-linux-musl, aarch64-unknown-linux-musl, x86_64-apple-darwin, and aarch64-apple-darwin. Preserve clickhousectl-{target}-{tag}.tar.gz and the existing internal archive layout. Public URLs are https://builds.clickhouse.com/clickhousectl/<archive-name>. Copy the release bytes; do not rebuild or repackage them. PyPI wheels are a separate output.

Work

1. Adapt the existing uploader into this repo and integrate it with the release workflow for the exact tag being released, rather than discovering whichever release happens to be latest. Reuse the complete, smoke-tested artifact set from that run or its tagged GitHub release assets.
2. Coordinate with the S3/infrastructure owner to obtain and configure upload credentials for this repository. Prefer an approved GitHub OIDC role if available, otherwise the approved release-secret mechanism. Scope access to the clickhousectl bucket prefix and use the appropriate protected release environment. The existing self-hosted runner's access must not be assumed to transfer to this repo. Record the owner/setup dependency; never place credential values in the issue or repository.
3. Make publication ordering close the race: all expected public builds URLs must serve the matching archives before GitHub advertises the version as latest and before dependent package publication such as npm. A draft-release → upload/verify → publish sequence, or uploading the same workflow artifacts before public release creation, can achieve this. Simply adding a job after the current public release step leaves an update-availability window.
4. Support safe retries and partial-upload recovery for a specific tag. Validate existing objects rather than silently accepting a mismatched archive. Report failures clearly and prevent publication from proceeding when mirroring/verification fails. Keep uploads restricted to valid release-tag runs; a manual workflow run on a branch must not upload branch-named artifacts.
5. Coordinate cutover with the main ClickHouse repository: after the replacement is proven, retire its clickhousectl nightly upload job through the workflow's source/generation path. Preserve old release objects. Record both implementation and upstream cleanup PRs here.

Acceptance criteria

• Approved S3 access is configured for this repository and its setup/ownership documented.
• One release run automatically uploads all four exact archives to the existing S3 prefix; no daily poll or manual copy is required.
• Each public builds.clickhouse.com URL is verified for availability and byte/content integrity before latest-release announcement and npm publication.
• Missing assets, an upload failure, or a partially visible mirror prevents announcement/publication and produces an actionable job failure; rerunning the same tag safely completes recovery.
• Focused checks cover complete uploads, missing assets, retry/existing-object behavior and workflow ordering. A controlled end-to-end release verifies CLI update/quick-install and npm download paths immediately after publication.
• New Actions dependencies use SHA pins and upload credentials are unavailable to untrusted PRs/non-release runs, following AGENTS.md.
• The upstream nightly uploader is retired after successful cutover, and the release workflow documentation is updated.

Milestone: v0.5.1. Follow-up tracker: #939. No credential provisioning or workflow implementation is performed by raising this issue.