ci(publish): build and publish container runner release artifacts

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #5394 refactor(container-runner): rewrite on rivetkit actor runtim …
• #5395 feat(rivetkit): re-export serverless_http and default absent …
• #5392 docs(deploy): add container runner page
• #5393 ci(publish): build and publish container runner release arti … 👈
• #5391 feat(container-runner): add container runner crate and e2e h …
• main

Get stack: forklift get 5393
Push local edits: forklift submit
Merge when ready: forklift merge 5393

_{change lysuzroz}

[claude]

Review

Small, well-scoped CI change that adds a container-runner build lane to the existing publish matrix and R2 pipeline. Traced the wiring end-to-end and it is correct.

What checks out

• Matrix entries (linux-x64-musl / linux-arm64-musl, release_only: false) mirror the existing cli/engine musl entries exactly, including the RUSTFLAGS="-C target-feature=+crt-static -C link-arg=-static-libgcc" static-linking flags.
• Dockerfile build branches use the correct package/bin name (rivet-container-runner), correct target triples, and correct artifact filenames.
• --name container-runner is passed consistently to both upload-r2 and copy-r2, and the --name option already exists in scripts/publish/src/ci/bin.ts (added by a prior stacked PR), so this is not calling an undefined flag.
• Artifact naming matches the consumer side: container-runner/examples/test-server/Dockerfile already documents curl https://releases.rivet.dev/rivet/latest/container-runner/rivet-container-runner-x86_64-unknown-linux-musl, which lines up exactly with the rivet/{version-or-latest}/container-runner/{artifact} R2 path this PR produces. Good end-to-end consistency check.
• TLS: rivet-envoy-client native-transport feature uses rustls, and the workspace reqwest dependency is already rustls-only (no OpenSSL), so static musl linking should not hit the usual OpenSSL/musl cross-compile pain.
• No secrets or credentials are newly introduced; it reuses the existing R2_RELEASES_* secrets already scoped for engine/CLI uploads.

Minor, non-blocking observation

There is now a second, independent way to produce this same binary: container-runner/Dockerfile.release builds a linux/amd64-only artifact from a bare rust:1-bookworm image, separate from this new CI path which builds musl x64+arm64 via the shared builder-base image. Worth a follow-up to either point the Dockerfile.release doc comment at the new CI-published binary or fold it into the new pipeline, so the two build recipes do not drift (for example toolchain versions diverging between rust:1-bookworm and the pinned RUST_TOOLCHAIN used in the musl Dockerfiles). Not a blocker for this PR.

Test coverage

No tests added, which is appropriate for a pure CI/build-config change; the real validation is a preview publish run exercising the new matrix entries and confirming the R2 objects land at the expected path.

Overall: looks correct and ready to merge pending a real CI run to confirm the new matrix jobs build and upload successfully.