Windows: response files accumulate in %LOCALAPPDATA%\Temp instead of a .fbuild-managed temp dir

[zackees]

Observed on Windows with a large number of fbuild response files accumulating directly under %LOCALAPPDATA%\\Temp.

Current temp contents on my machine:

• C:\Users\niteris\AppData\Local\Temp
• 14,365 files matching fbuild_*.rsp
• total size: 95,641,604 bytes (~91 MB)
• prefix counts from the filenames:
  • lib: 10,256
  • arm: 1,878
  • esp8266: 759
  • ch32v: 562
  • sam: 560
  • avr: 186
  • teensy: 86
  • esp32: 78

The filenames match the current response-file writer exactly:

• crates/fbuild-core/src/response_file.rs
  • windows_temp_dir() resolves to %LOCALAPPDATA%\\Temp
  • write_response_file() writes stable files named fbuild_<prefix>_<hash>.rsp
• crates/fbuild-paths/src/lib.rs already defines the app-owned roots under ~/.fbuild/{dev|prod}

The practical problem is that these files land in the global Windows temp directory, so fbuild cannot manage them as part of its own cache / GC lifecycle. They just accumulate as temp pollution.

Requested fix:

1. Put Windows response files under an app-owned temp directory inside .fbuild instead of %LOCALAPPDATA%\\Temp.
   • For example: ~/.fbuild/{dev|prod}/tmp/response-files/
   • Or project-local .fbuild/build/.../tmp/ if that is the intended ownership boundary
2. Add GC / startup cleanup for stale response files in that owned directory
3. Optionally add a one-time cleanup or migration path for legacy fbuild_*.rsp files already left in %LOCALAPPDATA%\\Temp

Even if some newer call sites already use output-adjacent tmp/ directories, the global-temp writer is still leaving fbuild_*.rsp files behind in practice.