ci: upstream maturin-action bug — host-build-script purge checks debugBuildDir instead of releaseBuildDir

[dean0x]

Context

At tag v1.51.0 (commit e83996d), PyO3/maturin-action's src/index.ts line 808 contains:

if (existsSync(debugBuildDir)) {

where the intent is to purge host-built build scripts before a containerized cross-compile. The variable should be releaseBuildDir. Because debugBuildDir is checked instead of releaseBuildDir, the purge never fires for release-only builds, and stale host-built build scripts can survive into the container environment.

Additionally, the purge only covers target/*/build and misses proc-macro .so files in target/release/deps/, which are subject to the same host-vs-container ABI mismatch.

Workaround In This Repo

PR #347 worked around this by:

1. Giving each build-python Linux leg its own Swatinem/rust-cache key (key: ${{ matrix.target }}-${{ matrix.manylinux }}), so no cross-leg cache bleeding can occur.
2. Skipping the dead host toolchain install on containerized Linux legs (the toolchain was installed but immediately purged incorrectly, serving no purpose).

This workaround is currently in place and the build-python jobs are green. It does not fix the upstream bug.

Why It Matters

The upstream bug is still present on maturin-action's default branch. If we ever remove our per-leg cache keys (e.g. during a future cleanup or version bump of Swatinem/rust-cache), the original failure mode returns. Separately, other repos using maturin-action in release-mode containerized builds are affected without our workaround.

Acceptance Criteria

• File a bug report against PyO3/maturin-action referencing src/index.ts:808, the debugBuildDir/releaseBuildDir swap, and the missing target/release/deps/ coverage.
• Link the upstream issue/PR from this issue once filed.
• If a fix is merged and released upstream: evaluate whether our per-leg key: workaround in release.yml can be simplified, and update release.yml accordingly. A simplified cache config is not strictly required — the workaround is correct and harmless — but it should be revisited to avoid misleading future maintainers.
• If the upstream project is unresponsive after 60 days: document the permanent workaround in release.yml inline comments so future maintainers understand why the per-leg keys exist.