Publish release images to GHCR and a CLI that defaults to them

[Tomer Glottmann (tomergee)]

What

Make the images of this repo something a customer downloads rather than builds.

• .github/workflows/release.yaml: on every v* tag, or by hand for an existing tag, builds ate-env-api and ate-env-guest with ko for linux/amd64 and linux/arm64, pushes them to ghcr.io/agent-substrate/env/<image> tagged with the release and latest, signs them with cosign keyless signing (bound to this repo's Actions identity), builds the ate-env CLI for linux and darwin on amd64 and arm64 with the two digests baked in, and uploads binaries, images_<tag>.txt and checksums as release assets. The release notes get an ## Images section with the digests and the verify command; a republish replaces it instead of duplicating it.
• CLI defaults: a release binary's ate-env manifest --api-image and ate-env manifest template --guest-image default to the release's images, so the quickstart needs no image flags for this repo. ate-env --version prints the tag. A source build keeps the flags required, with messages that explain the two cases. make build-cli reproduces a release-style binary locally.
• --worker-image stays required. ateom-gvisor is a Substrate image and must match the Substrate version on the cluster; Substrate publishes nothing yet, so the message points at building it there. That is the remaining piece for a zero-build customer experience and belongs to the Substrate repo.
• .github/workflows/ci.yaml: Go build, vet, tests, license headers, and the Python client tests on PRs and main. The repo had no checks before.
• .ko.yaml: the guest's bash base pinned by digest, so a published guest image is reproducible.
• docs/release.md: artifacts, pinning by digest, signature verification, cutting and republishing a release, the one-time organization setup for GHCR. README: Installation and a new Images section; quickstart commands updated.

Why this shape

• Digests, not tags, everywhere a customer copies something: Substrate requires pinned images in templates and latest moves.
• Baking the digests into the CLI makes "download the binary, run ate-env manifest" work without reading release notes, and keeps the CLI and the images of one release consistent by construction.
• Keyless signing costs one step and gives customers a way to check provenance that does not depend on us managing keys.

First-time setup (maintainers, once)

1. Organization settings → Packages: allow GitHub Actions to create packages.
2. Push a tag (git tag -a v0.0.11 -m v0.0.11 && git push origin v0.0.11), watch the release workflow.
3. Open the two packages that appear, confirm they are public and linked to this repository.

Testing

• go test ./... passes; new test covers the source-build and release-build flag defaults and the worker-image message.
• make build-cli ATE_ENV_API_IMAGE=... ATE_ENV_GUEST_IMAGE=... VERSION=v9.9.9 produces a binary whose --version and flag defaults carry the values, which is exactly what the workflow does.
• Both workflow files parse as YAML; every run: block passes bash -n; every referenced action tag exists. The Python CI steps were run locally as written.
• The release workflow itself cannot run before it is on main and a tag is pushed; the first tag is the real test, and workflow_dispatch exists to rerun it without a new tag.

Relation to other PRs

Independent of #69 and #70. Once this lands and a release is cut, the docs in #70 can name the published guest image instead of a placeholder.