fix(minimal): gate min stop on the daemon being down, not on the RPC transport - #1011

…C transport

`min stop` succeeds when the daemon is stopped, so judge it by that rather
than by the liveness of the transport that carried the request.

On a VM target minimald IS the guest's pid-1: an accepted Shutdown tears the
VM — and with it the SSH transport — down as a direct consequence of
succeeding. The client drains the channel and only then decodes what it
collected, so a reply lost on the way out decodes an empty buffer and fails
with "decode response for shutdown". Since #919 stopped swallowing RPC and
connection errors that surfaces as a non-zero exit for a stop that did
exactly what was asked — the assertion the nightly session-e2e-soak trips.

A failed Shutdown RPC no longer bails on the spot. It falls through to the
same wait an accepted shutdown runs, then re-asks the liveness probe the
command opened with: a native minimald has no lifecycle state to poll, so
its wait returns at once saying nothing, and only the probe can answer for
that backend. A daemon confirmed down is a successful stop; one still there
returns the original RPC error, context intact.

Only that failure arm probes. An accepted shutdown is still judged by its
wait alone, because the daemon acknowledges before it has finished going
down and asking again there would race its own teardown. SessionsLive keeps
its message and its non-zero exit, and the already-down fast path is
untouched.

The e2e's stop assertion now keeps stderr instead of discarding it: it threw
away the one piece of text that says why a stop failed, which is why this
needed a hypothesis rather than a log.

Closes gominimal/inbox#363

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>