fix(cli): exit cleanly when stdin is an open pipe that never closes

[artogahr]

Hi folks, this is something that was bothering me for a while, so I thought I would go ahead and make a PR for it.

What's wrong

When stdin is connected but never closed, which is what you get from anything spawning the CLI with stdio: ['pipe', ...] (e.g. claude code), every command finishes its work, prints all of its output, and then never exits. Reported in #1206, and it's the visible symptom in #1187 as well.

Why it happens

src/entrypoints/_shared.ts awaits readStdin() before running any command. For socket-type stdin there's a 50ms timeout so the CLI doesn't wait forever, but the abort path returned with the 'data' listener still attached and the stream still flowing. That single open handle keeps the event loop from draining. There's no process.exit() on the normal path, the process relies on the loop emptying out, so it hangs after the command is done. A stack sample of a hung process shows the main thread idle in uv__io_poll.

The fix

readStdin now removes its listener and pauses the stream in a finally block. pause() releases the loop for every stdin type Node hands out, and it's the safest of the options: fs.ReadStream stdin (from < file) has no unref(), and destroying fd 0 would break set-value, which streams process.stdin as the upload body.

A nice side effect: the leftover flowing listener used to eat any stdin bytes that arrived after the 50ms abort, which could silently truncate set-value uploads. Those bytes now stay buffered in the paused stream and upload in full.

Regression test

test/e2e/commands/stdin-held-open.test.ts spawns the built CLI with stdin held open and checks that it exits on its own. It passes on this branch in about half a second, and fails with a timeout if you strip the fix back out of the bundle. It needs dist/ built, so it lives in the e2e suite and runs with pnpm run test:e2e, not test:local.

What this doesn't fix

These all predate the change and behave the same before and after:

• A FIFO that never closes (tail -f /dev/null | apify ...) still hangs at startup, since no timeout is armed for FIFOs.
• Socket stdin that sends at least one byte within the 50ms window and then stays open also still hangs at startup. The first chunk cancels the timeout and 'end' never comes.
• The leaked keep-alive TLS sockets from datasets get-items finishes but never exits — leaked keep-alive sockets pin the process (1.6.1 & 1.6.2) #1187 can pin the process on their own.

The first two need the lazy stdin reading discussed in #1206.

I've verified this change separately with Fable and Kimi K3.