feat(minimal): upload project files to session on activate - #748

The shared session e2e only proved the lifecycle; it never forked a
session sandbox. Deepen it, on every lane, to attach an interactive shell
— which forks a real hakoniwa sandbox (on a VM lane, inside the guest over
the vsock bridge) — and prove the in-sandbox `min` helper: record a
genuinely-absent tool (jq — the shell stack composes base + curl, and jq
is pulled in by neither) as absent, `min add` it, then run it; its version
banner round-tripping proves `min add` reached the daemon over the
/run/minenv_sock relay and hardlinked the package into the live rootfs.

A session is interactive by design, so the proof drives it like a real
user through a REAL pty (scripts/e2e-attach-pty.py): pump the command
stream, then answer the session-exit Detach/Delete prompt with keystrokes
(Down + Enter => Delete). A pipe is not a tty and cannot answer that
prompt. Selecting Delete tears the session down, so it must be delisted.
Output is matched with a bash glob, not `printf | grep -q`, so `min add`'s
progress-bar flood cannot SIGPIPE a pipefail false-negative. A host-side
minimal.toml is seeded (uploaded to the session since #748) so the client
pre-flight neither prompts nor bails (#758); every seed is removed on
teardown.

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

The shared session e2e only proved the lifecycle; it never forked a
session sandbox. Deepen it, on every lane, to attach an interactive shell
— which forks a real hakoniwa sandbox (on a VM lane, inside the guest over
the vsock bridge) — and prove the in-sandbox `min` helper: record a
genuinely-absent tool (jq — the shell stack composes base + curl, and jq
is pulled in by neither) as absent, `min add` it, then run it; its version
banner round-tripping proves `min add` reached the daemon over the
/run/minenv_sock relay and hardlinked the package into the live rootfs.

A session is interactive by design, so the proof drives it like a real
user through a REAL pty (scripts/e2e-attach-pty.py): pump the command
stream, then answer the session-exit Detach/Delete prompt with keystrokes
(Down + Enter => Delete). A pipe is not a tty and cannot answer that
prompt. Selecting Delete tears the session down, so it must be delisted.
Output is matched with a bash glob, not `printf | grep -q`, so `min add`'s
progress-bar flood cannot SIGPIPE a pipefail false-negative. A host-side
minimal.toml is seeded (uploaded to the session since #748) so the client
pre-flight neither prompts nor bails (#758); every seed is removed on
teardown.

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

The shared session e2e only proved the lifecycle; it never forked a
session sandbox. Deepen it, on every lane, to attach an interactive shell
— which forks a real hakoniwa sandbox (on a VM lane, inside the guest over
the vsock bridge) — and prove the in-sandbox `min` helper: record a
genuinely-absent tool (jq — the shell stack composes base + curl, and jq
is pulled in by neither) as absent, `min add` it, then run it; its version
banner round-tripping proves `min add` reached the daemon over the
/run/minenv_sock relay and hardlinked the package into the live rootfs.

A session is interactive by design, so the proof drives it like a real
user through a REAL pty (scripts/e2e-attach-pty.py): pump the command
stream, then answer the session-exit Detach/Delete prompt with keystrokes
(Down + Enter => Delete). A pipe is not a tty and cannot answer that
prompt. Selecting Delete tears the session down, so it must be delisted.
Output is matched with a bash glob, not `printf | grep -q`, so `min add`'s
progress-bar flood cannot SIGPIPE a pipefail false-negative. A host-side
minimal.toml is seeded (uploaded to the session since #748) so the client
pre-flight neither prompts nor bails (#758); every seed is removed on
teardown.

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

… every lane (#760)

* fix(checkouts): report exit status on git command failure

A failed git command surfaced only its stderr. When git is killed by a
signal (e.g. OOM mid-fetch) stderr holds only whatever it wrote before
dying — which can be a misleadingly benign line such as a "templates not
found" warning, masking that the process was killed rather than failing
cleanly.

Include the rendered ExitStatus (exit code or signal) in GitCommandFailed
and its mctx wrapper, so a signal kill is distinguishable from a
git-reported error.

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

* test: exercise the session sandbox via interactive attach

The shared session e2e only proved the lifecycle; it never forked a
session sandbox. Deepen it, on every lane, to attach an interactive shell
— which forks a real hakoniwa sandbox (on a VM lane, inside the guest over
the vsock bridge) — and prove the in-sandbox `min` helper: record a
genuinely-absent tool (jq — the shell stack composes base + curl, and jq
is pulled in by neither) as absent, `min add` it, then run it; its version
banner round-tripping proves `min add` reached the daemon over the
/run/minenv_sock relay and hardlinked the package into the live rootfs.

A session is interactive by design, so the proof drives it like a real
user through a REAL pty (scripts/e2e-attach-pty.py): pump the command
stream, then answer the session-exit Detach/Delete prompt with keystrokes
(Down + Enter => Delete). A pipe is not a tty and cannot answer that
prompt. Selecting Delete tears the session down, so it must be delisted.
Output is matched with a bash glob, not `printf | grep -q`, so `min add`'s
progress-bar flood cannot SIGPIPE a pipefail false-negative. A host-side
minimal.toml is seeded (uploaded to the session since #748) so the client
pre-flight neither prompts nor bails (#758); every seed is removed on
teardown.

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

* ci: provision gvproxy for the KVM/macOS session-e2e lanes

The KVM and macOS session-e2e lanes boot a microVM whose guest daemon
clones the upstream `pkgs` repo during session mint. That clone needs the
guest's egress — NAT + DNS — which minvmd provides by spawning gvproxy as
the per-host-VM switch. Neither lane provisioned the gvproxy binary, and
its resolution is best-effort (never errors), so minvmd booted the VM
switchless: the guest's overlay had no other end and every egress —
including the clone — died with "Could not resolve host: github.com".

Fetch the pinned gvproxy (scripts/fetch-gvproxy.sh, already used by the
native minimald-root-integration job) and point minvmd at it via
MINVMD_GVPROXY_BIN on each lane's session-e2e step. The macOS lane's
fetch auto-selects the gvproxy-darwin asset.

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

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>