Fix subprocess helper exec on macOS

[marketchedai]

Fixes #4991.

xls/common/subprocess.cc cannot compile on macOS: it unconditionally uses
<linux/memfd.h>, memfd_create()/MFD_CLOEXEC, and the /proc/self/fd/<fd>
path passed to posix_spawnp(). macOS has none of these.

This introduces GetSubprocessHelperPath(), which encapsulates producing an
exec'able path for the embedded helper:

• Linux — behavior unchanged. Still writes the helper to a memfd and
  returns /proc/self/fd/<fd>, holding the descriptor open for the lifetime
  of the process.
• Apple. Materializes the helper into a temporary file via mkstemp(),
  marks it executable with fchmod(0700), and unlinks it through
  std::atexit() (the error paths unlink it too).

A named file is unavoidable on macOS. Unlike a memfd it is not reclaimed
automatically, and it cannot be unlinked up front because exec resolves it by
path. I checked the alternatives rather than assuming: exec'ing an unlinked
file through /dev/fd/<fd> is rejected with EACCES, and there is no
fexecve(). A process killed by a signal will still leave one behind.

The call site in ExecInChildProcess() is deliberately not platform-guarded —
the whole point is that the platform difference lives in one function.
subprocess_helper is now a reference to a function-local static const,
which has thread-safe initialization, is never mutated, and outlives the
c_str() pointers handed to posix_spawnp().

Testing

Tested on macOS (arm64, macOS 26.6.2) only. The Linux path in this change
has not been compiled anywhere — I do not have a Linux machine available, and
I could not cross-check locally: undefining __APPLE__ to force the other
branch breaks macOS's own libc++ headers, which key off that macro. I am
relying on CI for Linux coverage, and would appreciate a careful look at the
#else branch.

On macOS arm64, with Bazel 8.7.0:

• //xls/common:subprocess_test passes (12 tests, covering non-zero exits,
  crashing children, large stdout/stderr, and environment variable
  propagation). Note this requires xls_cc_embed_data: shared-library link fails on macOS — ELF-only -soname passed to the Mach-O linker #4992 to be fixed first, otherwise the test
  cannot be built on macOS at all.
• //xls/common/... passes 36/36.
• interpreter_main, ir_converter_main, opt_main and codegen_main all
  build, and a DSLX -> IR -> opt -> Verilog run produces correct output.
• Confirmed no temporary files accumulate: repeated runs leave none behind.

🤖 Generation assisted with Claude Code

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[allight]

We are already reviewing #4972 for this.

[marketchedai]

Thanks @allight — agreed, #4972 supersedes this, and it is the better fix: a
proper per-OS split selected by Bazel rather than more #ifdefs inside one
file. Closing in favour of it.

For anyone finding this later: #4972 merged as 2257034 and removes the
memfd_create() / /proc/self/fd dependency from subprocess.cc entirely.

Note that #4993 is a separate problem and is still outstanding on current
main: xls_cc_embed_data still builds a shared library, which fails to link
on macOS because the toolchain passes the ELF-only -soname to the Mach-O
linker. That still blocks building //xls/common:subprocess_test on macOS.