engine: default CARGO_TARGET_DIR/TMPDIR off the data volume

[Morgandri1]

Summary

PM ruling: this is both the ENOSPC root cause (a cargo build --workspace on the small persistent /data volume fills it — hit live by me and by API independently this session) and the biggest measured contributor to the reported 7-8GB memory number (page cache from that build I/O counts against the project's cgroup).

Every spawned child now gets CARGO_TARGET_DIR and TMPDIR under /tmp/wheel-scratch/<project_id>/, created 0700 and checked the same way cargo_home() already is (refuses a symlink, refuses a mode that won't stick). Unlike CARGO_HOME, which deliberately stays on the project's data dir (a small, worth-persisting registry cache), this is disposable build output that runs to gigabytes and belongs off the persistent volume.

Refactored the create/verify/tighten dance out of cargo_home() into a shared private_dir() helper so the same security property (private to this project's uid, belt-and-braces against a symlinked shared directory) isn't re-derived per scratch dir.

Test plan

• cargo build --workspace — clean
• cargo test -p wheel-engine — 278 passed, including 3 new tests: the_scratch_dirs_are_off_the_data_volume_and_private, two_projects_get_different_scratch_dirs, the_child_actually_receives_the_off_volume_scratch_dirs
• cargo clippy -p wheel-engine --all-targets -- -D warnings — clean
• cargo fmt -p wheel-engine -- --check — clean
• Mutation-checked: reverted the CARGO_TARGET_DIR env line, confirmed the_child_actually_receives_the_off_volume_scratch_dirs fails; restored

[vercel]

Deployment failed for project wheel with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/morgandri1s-projects?upgradeToPro=build-rate-limit