fix(acq): piping acq create/start stderr hangs until the sandbox stops #568

Problem

When an acq verb's stderr is piped, the pipeline never returns, even though the verb finished
successfully:

./acq create shell ~/src/myrepo 2>&1 | tail -20   # sandbox is up; the pipeline never exits

The sandbox is healthy. The pipe reader never gets EOF because the msb VM process keeps a copy of
acq's stderr open for as long as the sandbox runs. Any script or CI step that pipes, tees, or
$(...)-captures acq with 2>&1 can hang the same way. docs/KNOWN_FAILURE_MODES.md §44 hit this
in scripts/verify-backends and worked around it there by capturing to a file.

Root cause

acq.backends/secret-store.sh runs exec 9>&2 at load (the warning channel) and never closes fd 9
for children. msb create/msb start launch the long-lived msb machine process, which inherits fd 9.
The comment there calls the inheritance harmless; it is not when stderr is a pipe.

Reproduction (macOS, msb 0.7.7, default image, about 1 minute)

Holder found with lsof on the reader's pipe after acq exited. Offline, sourcing secret-store.sh and
starting any background child reproduces it with no sandbox.

Proposed fix

1. Close fd 9 for anything acq spawns that can outlive it, at least every msb invocation (9>&-).
   Alternatively, scope the dup to the read paths that need it rather than holding it for the whole
   process. Correct the "harmless" comment either way.
2. Add a bats guard like test/bats/145-verify-capture.bats: run a verb against a stub msb that
   daemonizes a child, capture with $( ... 2>&1 | cat) under timeout, and fail on timeout.

Workaround until then: redirect to a file (acq create ... > log 2>&1) instead of piping.

AI-assisted.