## Why
Prepare CI jobs for a later build-output relocation without changing
where they write today.
## What
- Export `CARGO_TARGET_DIR` from `setup-ci` at the existing
`codex-rs/target` path.
- Route nextest, release, artifact, and signing paths through
`CARGO_TARGET_DIR`.
- Require V8 staging callers to pass an explicit target directory while
preserving the existing upstream path.
## Manual validation
- Ran `just test-github-scripts`.
- Parsed GitHub Actions YAML with `yq`.
## Stack
- [#31332](https://github.com/openai/codex/pull/31332) — parameterize
Cargo target paths
- [#31356](https://github.com/openai/codex/pull/31356) — Windows 2025
runner bump
- [#31357](https://github.com/openai/codex/pull/31357) — Dev Drive I/O
routing
## Why
CI jobs repeat common bootstrap steps, which makes it harder to keep
Bazel and Cargo lanes aligned. Centralizing the lightweight setup gives
us one place for future runner-wide optimizations without adding Rust
toolchain or component installation to the Windows Bazel long poles.
## What
- add zero-input `.github/actions/setup-ci` to set Cargo's git
transport, install DotSlash and `just`, expose DotSlash from stable PATH
locations, and enable Windows Git long paths
- have `setup-bazel-ci` compose the common setup, then remove its
DotSlash/test-prerequisite plumbing
- migrate Bazel, Cargo CI, V8 canary, repo checks, nextest, and Windows
release call sites while keeping Rust toolchain and MSVC setup explicit
- preserve the existing nextest Dev Drive setup unchanged
## Validation
- `just test-github-scripts` (30 tests)
- parsed workflow and composite-action YAML with `yq`