fix(core): avoid deadlock on here-documents larger than the pipe buffer

[cataggar]

Found while running an 88k-line bash CLI (kenji-cli) under brush on Windows: every cat <<EOF-based help function hung the shell.

Root cause

setup_open_file_with_contents creates an anonymous pipe and writes the entire here-document / here-string payload into it before the reading command exists. That write can only complete while the payload still fits in the pipe's buffer, so any larger payload blocks forever.

Linux papered over this by growing the buffer to the payload size with F_SETPIPE_SZ. Every other platform kept the default buffer — 4 KiB on Windows — so a here-document past that threshold hangs.

Bisected to an exact threshold on Windows: OK at 4096 bytes, hangs at 4160.

The Linux path had two latent gaps of its own. The fcntl result is propagated with ?, so it also failed outright for:

• payloads larger than /proc/sys/fs/pipe-max-size (1 MiB by default for unprivileged processes)
• zero-length payloads

Fix

Keep the resize as a best-effort fast path, and hand oversized payloads to a helper thread so the write proceeds while the reader drains. The thread ends when the payload is consumed, or earlier with a broken pipe if the read end is dropped by a command that never reads its stdin.

Testing

• 2 new compat cases covering here-doc and here-string payloads larger than the pipe buffer
• All 43 here-doc/here-string compat cases pass against the bash 5.2.15 oracle
• Full compat suite: 1784 passed, 5 failed — the same 5 fail on unmodified main (CRLF artifacts of a Windows checkout run under WSL), so no regressions
• cargo clippy and cargo fmt --check clean