Fix binary name resolution against custom PATH on macOS

[G36maid]

Closes #50536

Summary

Addresses #50536

• On macOS, posix_spawnp resolves programs against the parent process's cwd and environ (via getcwd and getenv("PATH")), ignoring the child's current_dir and envp. This causes two classes of failures when Zed spawns external commands via the custom posix_spawnp-based Command:
  • Bare names (e.g. "black"): resolved via the parent's PATH, not the child's — binaries only available in a project-specific PATH (Nix/direnv) are not found.
  • Relative paths (e.g. "./script.sh", "bin/test.sh"): resolved against the parent's cwd, not current_dir — only works when Zed's cwd happens to match the project root.
• Added program resolution in spawn_posix_spawn (crates/util/src/command/darwin.rs): before calling posix_spawnp, resolve the program to an absolute path — bare names via which::which_in against the child's PATH, relative paths via Path::join(current_dir). Falls back to the original program if resolution fails.

Root Cause

Apple's Libc implementation of posix_spawnp resolves the program path using the parent process's context — getcwd() for relative paths and getenv("PATH") for bare names — rather than the current_dir (set via posix_spawn_file_actions_addchdir_np) or envp argument. The child's working directory and environment only take effect after the binary has already been located. This is a well-documented macOS behavior that Rust's own std::process::Command works around by bypassing posix_spawn when PATH is modified (see rust-lang/rust#48624).

The regression was introduced when PR #49090 switched macOS from std::process::Command (which uses fork+execvp, correctly using the child's cwd and PATH) to a custom posix_spawnp-based implementation (which does not).

Testing

• test_bare_program_resolved_via_custom_path — bare name resolves via child's custom PATH
• test_bare_program_with_custom_path_falls_back_when_not_found — non-existent binary still errors
• test_bare_program_with_custom_env_no_path_key — custom env without PATH key falls back gracefully
• test_relative_path_skips_resolution — relative path resolves against current_dir instead of parent's cwd

Note: The fix and tests are in darwin.rs which is macOS-only. The Linux path uses smol::process::Command (via fork+execve) and is unaffected.

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content is consistent with the UI/UX checklist
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Release Notes:

• Fixed external formatters and language servers failing to launch on macOS when specified as a bare binary name or relative path and only available in the project's PATH (e.g. Nix, direnv)

[zed-industries-bot]

	Messages
📖	This PR includes links to the following GitHub Issues: #50536 If this PR aims to close an issue, please include a Closes #ISSUE line at the top of the PR body.

Generated by 🚫 dangerJS against f7a9398

[dnlzro]

Needed to add an import before it would build, but otherwise all good. Addresses the linked issue on my Mac.

[kubkon]

Looks great, thanks! I merged main and fixed a couple of tiny nits.