Windows: archiving a large local library fails with os error 206 (archive_objects passes every object on the command line) #1656

Summary

On Windows, archive_objects in crates/fbuild-library/src/library/library_compiler.rs
passes every object file to ar rcs as a separate argument. For a library with a few
hundred translation units the command line exceeds the 32,767-character
CreateProcess limit, and the build fails before linking:

build error: build failed: local library 'lvgl' failed to compile: failed to spawn
["C:\\Users\\<user>\\.fbuild\\prod\\cache\\toolchains\\toolchain-xtensa-esp-elf\\...\\xtensa-esp32-elf-ar.exe",
 "rcs", "<project>\\.fbuild\\build\\esp32_esp32_esp32\\release\\lib\\lvgl\\liblvgl.a",
 "<project>\\.fbuild\\build\\esp32_esp32_esp32\\release\\lib\\lvgl\\obj\\EVE_commands_f834.o", ...] (os error 206)

os error 206 is ERROR_FILENAME_EXCED_RANGE. The compile step already avoids this:
on Windows the compile invocation in the same file writes all flags to a GCC response
file (<compiler> @response.rsp), and #234 / #235 did the same for the Teensy link. The archive step is the
one remaining long command line.

Reproduction

• Host: Windows 11, fbuild 2.5.26. The code is unchanged on main as of 2026-10-07
  (2.5.37), so the failure is expected there too.
• Board: esp32dev (also esp32-s3-devkitc-1), Arduino framework.
• Library: LVGL 9.5.0 vendored under lib/lvgl. That is 525 object files. The object
  list alone is 71,251 bytes for esp32_esp32_esp32 and 74,401 bytes for
  esp32_esp32_esp32s3_opi; the failing command line we captured was 78,023
  characters.
• A sketch that includes <lvgl.h>, built with fbuild build -e <env>.

The project path length matters only at the margin: the object list is already more
than twice the limit.

Workaround we ship

Our helper catches this exact failure and re-runs the same archiver with the objects
in a response file, then lets the build continue:

xtensa-esp32-elf-ar.exe rcs <...>\lib\lvgl\liblvgl.a @<...>\lib\lvgl\lvgl-objects.rsp

GNU ar accepts @file. The recovery takes about a second. But the failing pass has
already compiled the whole library, so a build that needs it pays for the full compile
twice. Whenever LVGL has to be archived again, it shows up as a slow build.

Suggested fix

On Windows, or whenever the joined argument length would exceed about 30,000
characters, write the object paths to a response file and pass ar rcs <archive> @<file>. fbuild_core::response_file::write_response_file already does this for
compile flags, and the same quoting rules apply. The Unix behaviour can stay as it is.

Happy to test a build on our Windows bench.