1. 1. Summary

Follow-up to the custom build framework (#61193 on master, #61108 on v8.0). Today `custom_build_deliver` overwrites a single rolling object (`<prefix>/latest/mongodb-<arch>.tgz`) on every cron build, so there is nothing that corresponds to "the artifact for release X", and the only way to tell a consumer's support contact what was delivered is to hand-write a presigned URL that expires within a week.

This change makes the deliverable self-describing and release-addressable, so the hand-off can be automated with Evergreen's built-in notifications rather than scripted Jira comments:

• *Delivery channels* (`evergreen/custom_builds/prepare_upload.sh`): a version triggered by a release git tag (`${triggered_by_git_tag}`) delivers to an immutable `<prefix>/<version>/mongodb-<arch>.tgz` (e.g. `splunk/version/8.0.29-splunk-openssl3-rhel8/mongodb-rhel8-x86_64.tgz`) and fails if the tag does not match the version being built; commit/cron builds keep the rolling `<prefix>/latest/` path; patch builds keep their patch-specific path. Required expansions are validated up front.
• *Manifest*: every delivery also uploads `mongodb-<arch>.manifest.json` next to the tarball — version, suffix, git tag, revision, branch, project, variant, sha256 and size of the tarball, S3 URIs, and the Evergreen task/version/build ids and task URL. Written by python so values are JSON-safe; expansions are passed to it explicitly since prelude.sh defines them as unexported shell variables. A second `s3.put` in `custom_build_deliver` (`etc/evergreen_yml_components/custom_builds/tasks.yml`) uploads it with `visibility: signed`, so both objects are linked from the task's Files tab with on-demand signed URLs.
• *README*: new "Delivery layout and manifest" section, and "Surfacing a release delivery to its consumer" describing how to get release-tag versions to run the custom build variants — preferred: add the `release` variant tag so an existing release-tag alias that selects by that tag (as `mongodb-mongo-v8.0`'s does) picks them up, with a new project-settings alias as the fallback — plus a project-level notification (Slack / email / Jira comment / webhook) on `custom_build_deliver` success for git-tag versions, which links to the task and therefore to the deliverable. No credentials or notification code in the repo.

All new expansions written by `prepare_upload.sh` (`custom_build_manifest_remote_file`, `custom_build_delivery_channel`) are internal to the task. No variant changes are needed on master (no consumer variants live here); the Splunk variants on v8.0 pick this up — and opt into release tags via `tags: ["release"]` — in the backport #62190.

1. 1. Testing

• Dry-ran `prepare_upload.sh` in a fake Evergreen workdir (copied `evergreen/`, `expansions.yml` with the task's expansions, repo venv) for every channel: commit/cron → `splunk/version/latest/…`; patch → `custom-build-patches/<variant>/<version_id>/…`; git tag `r8.0.29` with version `8.0.29-splunk-openssl3-rhel8` → `splunk/version/8.0.29-splunk-openssl3-rhel8/…`; tag `r8.0.29` with version `8.0.28-…` → task fails with a clear message; missing `push_arch` → fails before any upload. Manifest fields verified populated (sha256 matches `sha256sum`).
• `evergreen validate p mongodb-mongo-master etc/evergreen_nightly.yml`: the only errors are the 35 pre-existing `release*` distro-allowlist errors also reported on unmodified master.
• `bazel run format` (shfmt, prettier) clean.
• Verification patch running `custom_build_deliver` on the v8.0 backport (the variants only exist there) linked in a comment below.

1. 1. Review fixes (Copilot)

• `custom_build_deliver` now regenerates the version expansions with the `set_version_override.sh` hook (same as `"bazel compile"`) before computing the destination: the shared per-version expansions never carry `MONGO_VERSION_OVERRIDE`, so the release path and manifest would otherwise have recorded the unsuffixed branch version. Verified with an end-to-end dry run of the get -> override -> apply -> prepare_upload chain in a fake Evergreen workdir, feeding the unsuffixed `version` CI actually provides: release path and manifest now carry `8.0.29-splunk-openssl3-rhel8`, tag mismatch still fails, patch/rolling channels unchanged.
• Release deliveries are now genuinely immutable: `prepare_upload.sh` emits `custom_build_skip_existing` (`true` only on the release channel; `skip_existing` is expansion-capable — `plugin:"expand"` in Evergreen's `s3_put.go`) and both `s3.put` commands use it, so rerunning a delivered release cannot replace the artifact or manifest behind its URI. Re-delivering requires deleting the objects first (documented in the README). Rolling and patch paths still overwrite.
• Side effect worth noting: with the regeneration in place, the rolling (cron) destination is derived from the suffixed version, so on v8.0 it moves from the drifting `splunk/version/r8.0.X/` to a stable `splunk/version/v8.0-latest/` (master: `latest`). Stable is what a rolling consumer URL should be, but it is a path change for anything already polling the old location.