fix(byoa): don't truncate large CLI output in the `cumora` shim (#25)

The shim ended with `process.stdout.write(text + '\n')` immediately followed by
`process.exit(code)`. When fd 1 is a pipe, Node's stdout is asynchronous, so
`process.exit()` tears the process down with the tail of that write still
buffered.

The engine always runs the shim with stdout piped, so every large result was
silently cut at the pipe buffer — 64KB, or 8KB on the socketpair a
`stdio: 'pipe'` parent hands us. Measured against the real shim with a 1MB
payload: 8,192 bytes delivered, exit code 0, empty stderr. Nothing signalled the
loss, so the agent simply read a truncated inbox or conversation and acted on it,
and `--json` output failed to parse for no visible reason. This is the agent's
main sense organ.

Exit from the write's completion callback instead of the next statement.

Deliberately not `process.exitCode = code` with a natural exit, which is the
more obvious-looking fix: it repairs truncation equally well but turns a reader
that closes early — `cumora doc read <id> | head`, a pattern the agent bash tool
invites — into an unhandled `Error: write EPIPE` crash dump. Measured both; the
callback form is the only variant that fixes the truncation while leaving every
existing exit-code and stderr behavior byte-identical.

One behavior change worth naming: the shim now waits for a stalled reader
instead of dropping data on the floor. That is correct behavior for any command,
and the shim's own network call is already unbounded, so it introduces no new
class of unbounded wait.

CUMORA_SHIM is exported so the tests can run the real shim text against a real
pipe — the only place this bug exists. The cloud pod's sibling shim
(server/docker/agent-computer-cumora.sh) uses blocking `printf` and was never
affected.