fix(frontend): isolate rustc response files in scratch directory

What changed

This introduces an explicit ctx["scratch_dir"] for Starlark target kind implementations and documents it in the public module reference.

The Rust target kind now writes Windows rustc response files under that scratch directory instead of the target build output directory. The related tests now assert the scratch path is exposed through analysis and that response files use it.

Why

The main branch release graph build on Windows was still failing after the full rustc invocation moved into response files. The failing compiler invocation reported missing dependency crates while compiling once-core, which points at the response-file helper path being too tightly coupled to durable build outputs.

Action-private helper files need a path chosen by analysis, not inferred by the executor and not mixed with target outputs. This keeps the action model explicit while giving target kinds a stable place for files that are materialized before an action runs.

Root cause

The Rust prelude used ctx["build_dir"] for response files. That directory is the durable output namespace for the target. Response files are not target outputs; they are action-private command-line materialization details.

Approach

The frontend analysis context now carries both paths:

• ctx["build_dir"] for declared target outputs.
• ctx["scratch_dir"] for action-private helper files.

The Rust prelude routes Windows response files through ctx["scratch_dir"], while keeping actual outputs and generated wrapper scripts in their existing declared locations.

Impact

Target kind authors get an explicit scratch path for helper files. Existing target output paths stay unchanged, and durable provider paths continue to use ctx["build_dir"].

Validation

• mise exec -- cargo fmt --all -- --check
• mise exec -- cargo test -p once-frontend
• mise exec -- cargo test --workspace

No GitHub comments yet.