fix(ci): stamp the release version into Linux binaries (#1602)

## Symptom

Linux standalone binaries (`mergify-x86_64-unknown-linux-gnu`, `mergify-aarch64-unknown-linux-gnu`) report `mergify 0.0.0` instead of the real calver (e.g. `2026.6.15.1`). The macOS arm64 and x64 binaries correctly report the version. Confirmed against the `2026.6.15.1` release assets.

## Root cause

`build-wheels.yml` line 110 sets `MERGIFY_RELEASE_VERSION` via `GITHUB_ENV`:

```
echo "MERGIFY_RELEASE_VERSION=${VERSION}" >> "${GITHUB_ENV}"
```

`GITHUB_ENV` makes the variable available in subsequent steps' **host** environment. However, for Linux targets `maturin-action` with `manylinux: auto` runs the Rust build inside a manylinux Docker container. The action only forwards env vars whose names match an allowlist of prefixes (`CARGO_*`, `GITHUB_*`, `MATURIN_*`, `RUST*`, `SCCACHE_*`, `TARGET_*`, etc. — see `PyO3/maturin-action` source). `MERGIFY_RELEASE_VERSION` doesn't match any allowed prefix and is silently dropped before the container starts.

Inside the container, `crates/mergify-cli/build.rs` doesn't see the variable and falls back to `CARGO_PKG_VERSION` (`0.0.0` — the semver placeholder Cargo uses because the 4-component calver is not valid semver). That `0.0.0` gets compiled into the binary via the `MERGIFY_CLI_VERSION` rustc-env.

macOS and Windows targets build natively on the runner and inherit the host environment directly, so they receive `MERGIFY_RELEASE_VERSION` correctly.

## Fix

Add `docker-options: -e MERGIFY_RELEASE_VERSION` to the `maturin-action` step in `build-wheels.yml`. Docker's `-e VAR` syntax (name only, no `=value`) copies the named variable from the host environment into the container at `docker run` time, so `build.rs` now sees the version during the Linux manylinux build.

The `docker-options` input is a no-op for non-containerised targets (macOS, Windows), so those platforms are unaffected. When `stamp-version` is false (PR smoke builds), `MERGIFY_RELEASE_VERSION` is unset on the host, so the container also sees it as unset and `build.rs` correctly falls back to `0.0.0`.

## Verification (by inspection)

Before: "Stamp wheel version" sets `MERGIFY_RELEASE_VERSION=2026.x.y.z` on the host → maturin-action spawns Docker → only `GITHUB_*`, `CARGO_*`, etc. are forwarded → `MERGIFY_RELEASE_VERSION` absent in container → `build.rs` emits `MERGIFY_CLI_VERSION=0.0.0`.

After: same setup, but `docker run` now also receives `-e MERGIFY_RELEASE_VERSION` → Docker copies `2026.x.y.z` from host into container → `build.rs` emits `MERGIFY_CLI_VERSION=2026.x.y.z` → `mergify --version` prints `mergify 2026.x.y.z`.

Author: kozlek

.github/workflows/build-wheels.yml

@@ -119,6 +119,15 @@ jobs:
           args: --release --strip --out target/wheels
           manylinux: auto
           sccache: true
+          # Forward MERGIFY_RELEASE_VERSION into the manylinux Docker
+          # container. On Linux maturin-action runs the build inside a
+          # container and only propagates env vars whose names match an
+          # allowlist of prefixes (CARGO_*, GITHUB_*, MATURIN_*, etc.).
+          # MERGIFY_RELEASE_VERSION doesn't match any prefix, so without
+          # this the variable is silently dropped and build.rs falls back
+          # to CARGO_PKG_VERSION (0.0.0). macOS and Windows build natively
+          # on the runner and inherit the host env, so they were unaffected.
+          docker-options: -e MERGIFY_RELEASE_VERSION
 
       # `twine check --strict` validates the wheel's metadata against
       # the same rules PyPI's upload validator applies (README