Compare against Node.js/libuv internals

Did this — summary of the comparison and confirmation the fix matches:

libuv does no shell handling of its own. In uv__process_child_init it just calls execvp(options->file, options->args) (or posix_spawn on the eligible fast path) and writes back errno on failure — there is no /bin/sh fallback in libuv. So the fallback is entirely libc's.

glibc execvp (__execvpe → maybe_script_execute) does fall back, including for slash-containing paths:

if (strchr (file, '/') != NULL) {
  __execve (file, argv, envp);
  if (errno == ENOEXEC && exec_script)
    maybe_script_execute (file, argv, envp);   // exec_script = true for execvp
  return -1;
}

maybe_script_execute re-execs with new_argv = [_PATH_BSHELL ("/bin/sh"), file, argv[1], argv[2], ...] — i.e. the original argv[0] is dropped and /bin/sh runs file with argv[1..].

Net behavior, which matches the bug report:

• Linux: libuv's fork+execvp path hits glibc's fallback → ./script.sh runs via /bin/sh → works (what the reporter sees).
• macOS: libuv uses posix_spawn, which has no fallback → Node fails with ENOEXEC there (confirmed with a local C repro: posix_spawn returns ENOEXEC, while posix_spawnp/execvp print hello hello).

Deno hits the macOS-style failure on Linux because Rust's std::process::Command uses posix_spawnp, and glibc's posix_spawnp (unlike macOS's) does not implement the script fallback.

This PR replicates glibc's maybe_script_execute exactly:

• fallback triggers only on ENOEXEC (not EACCES — a non-executable file still fails like Node; covered by the added test);
• shell is /bin/sh；
• argv is [/bin/sh, cmd, ...args] with the original argv0 dropped (matching maybe_script_execute);
• applied to sync + async, Deno.Command and the node-compat op.

One intentional minor difference: we pass the resolved command path to /bin/sh (so $0 is absolute) rather than the original relative string, which is more robust across cwd changes and matches glibc's behavior for PATH-resolved names.