fix(cli): read stdin lazily so open pipes don't hang the CLI

[l2ysho]

Note

TL;DR — The CLI read stdin at startup for every command, so a pipe that stays open hung it forever. Now it only reads stdin when a command actually wants it.

Closes #1206.

_shared.ts read stdin at module scope (export const cachedStdinInput = await readStdin()), so every command blocked on stdin whether or not it uses it. #1294 fixed the socket case (a spawned child's stdio: 'pipe'), but a named pipe has no wait deadline — the read never ended and the command never even ran, so 1.8.0 still hangs with no output at all:

sleep 60 | apify --version   # 1.8.0: hangs, no output

Read stdin only where it's asked for: a - arg/flag, apify run without --input, push-data/push-items without an item arg. readStdin() memoizes, since stdin can only be drained once.

Confirmations keyed off hasData, which the eager read flipped to false after draining. Without that read it stays true, so apify <confirm-cmd> < /dev/null would try to prompt on a non-TTY — gated on isTTY instead.

Unchanged by design: commands that genuinely consume stdin still wait for the writer to close, same as cat.

Verification

New e2e case: real FIFO via mkfifo, opened r+ so it never EOFs (skipped on Windows). Fails on the pre-fix build (60s timeout), passes after.

stdin	before	after
open pipe, no data	hang, no output	exits 485 ms
open pipe, with data	hang, no output	exits 423 ms
closed pipe	exits	exits 417 ms
spawn stdio: 'pipe' (socket, #1294's case)	exits	exits

pnpm run test:local green (2 pre-existing python-fixture failures, fail on master too — local python env). No dependency or install-size change.

🤖 Generated with Claude Code