feat(minimald,sandbox2): rootless host-native (DM2) own-ip networking - #589

`build-initramfs.sh` always shelled out to `cross` (Docker), so hosts
without Docker could not build the guest initramfs (`cross: not found`).
Auto-detect a same-arch native static-musl toolchain (the `*-linux-musl`
rustup target plus a matching `*-linux-musl-gcc` linker) and build
natively in that case, deriving the cargo linker-override var from the
target triple; otherwise fall back to `cross`. `FORCE_CROSS=1` keeps the
container path. This is what lets the `dm3`/`up` recipes build the guest
on a plain Linux host.

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

Explicit per-deployment-model bring-up recipes:
- `dm1` — macOS + Linux VM over Hypervisor.framework (the `up` path on
  macOS); a clean SKIP on Linux.
- `dm2` — native Linux host-native minimald (no VM) over UDS. Builds the
  daemon, applies `setcap cap_net_admin,cap_sys_admin=ep` (re-applied each
  bring-up; `cargo build` strips file caps), and starts it with
  `--gvproxy-bin` so own-IP needs no system gvproxy install.
- `dm3` — native Linux + one Linux VM, bridging the CLI socket to minvmd's
  guest bridge (the F1 path mismatch).

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

Enable hakoniwa's `rustslirp` feature for rootless own-IP, pinned to the
gominimal fork of souk4711/hakoniwa (rev 44969f2) which carries the
RustSlirp `gateway()` next-hop-route support (`RustSlirpGateway::
IfaceWithAddr`). Repoint to upstream once that lands.

The rustslirp feature pulls tun-rs 2.8.3 -> c2rust-bitfields 0.22, whose
derive macro exact-pins `proc-macro2 = "=1.0.103"`. clap_derive 4.6
requires `proc-macro2 >= 1.0.106`, which the resolver cannot unify with
`=1.0.103`. Holding clap/clap_complete at 4.5 (which needs only
`proc-macro2 ^1.0`) lets the resolver settle on 1.0.103. Bump back to 4.6
once tun-rs/c2rust relax that pin.

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

Replace the native (DM2) own-IP tap setup with hakoniwa's RustSlirp, which
builds and configures the tap *inside* the sandbox's own user+net namespace
(rootless — it acts as container-root and needs no host CAP_NET_ADMIN).
This removes the privileged path entirely: no `setcap`, no
`PR_SET_DUMPABLE`, and no in-process `setns` + tap ioctls.

Per review on #589 (thanks @twitchyliquid64): the own-IP tap creation now
lives behind `container.network(RustSlirp)` and the tap fd comes back via
`Child.rustslirp_tapfd`, which minimald relays to the gvproxy switch.

- sandbox2: a `Config::own_ip_tap` (`OwnIpTap { address, netmask, gateway,
  mtu }`) drives `container.network(RustSlirp::TAP …
  gateway(IfaceWithAddr(gw)))` in `new_container`, after the netns unshare.
  The next-hop route (`0.0.0.0/0 via gateway`) is required — gvproxy is a
  real gateway and does not proxy-ARP, so RustSlirp's default on-link route
  breaks egress.
- minimald: `EnvArgs::with_own_ip_tap` threads the lease into the sandbox.
  The session launch splits into two phases because RustSlirp needs the
  address before spawn: phase 1 (pre-spawn) allocates the lease + ensures
  gvproxy for the native `LocalSpawn` transport; phase 2 (post-spawn) wraps
  `Child.rustslirp_tapfd` and relays it via `complete_local_own_ip_attach`.
  Build/spawn failures roll the phase-1 attach back so gvproxy's refcount
  stays accurate.
- The in-VM DM1/3/4 (`HostShuttle`) path is unchanged — `attach_own_ip`
  keeps the proven open-tap + move-into-netns + vsock relay (minimald is
  root there); the two paths share `finish_own_ip_attach` (ingress + guard).
- Delete the now-dead in-process tap code (`open_tap_in_netns*`,
  `open_netns_fd`, `configure_switch_interface`) and
  `restore_sandbox_dumpable`.
- `dm2` recipe: drop the `setcap` step — own-IP is rootless now.

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

The native same-arch musl branch set `CARGO_TARGET_*_LINKER` but not
`CC_<triple>`, which cc-rs (used by ring's build script to compile its C/asm)
reads to pick the compiler. Export it alongside the linker so the musl
toolchain is used for the C objects too, not just the link (CodeRabbit #4).

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

The RustSlirp `gateway()` next-hop support (`RustSlirpGateway::IfaceWithAddr`)
merged into souk4711/hakoniwa upstream, so drop the interim gominimal fork pin
and track upstream directly (rev bc0abab). API-identical — no code change.

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

TC2's same-host-peer step drove two concurrent `minimal attach` sessions from
a single `expect` via two spawn ids read one-at-a-time. `attach` exec's
`ssh -tt`, whose pty has a fixed ~16KB kernel buffer; while the one process
drained session A, session B's ssh kept writing shell-setup into B's unread
pty until it filled and ssh blocked on write, so B's RequestShell never
reached the daemon. That looked like a server-side own-ip attach wedge ("first
attach works, the second hangs") but was the client starving its own pty —
and it cascaded 360s step-timeout SIGKILLs onto TC3/4/7/8.

Fixes (harness only; no product change):
- One pty per process: TC2 now runs the peer listener as a backgrounded
  `run_in_session` and dials it from a separate `session_out`, each draining
  its own pty. Documented as a RULE in the header.
- Line-buffer expect stdout (`fconfigure stdout -buffering line`) in
  `run_in_session` and the TC3/4/7/8 blocks, so a gtimeout SIGKILL can't
  discard a verdict stuck in expect's block buffer.
- Warm peer's sandbox (via the switch-IP read) before the timed trial, and
  retry demo's connect to absorb listener-bind latency.

Verified locally on DM2 (rootless own-ip): TC1/TC1b/TC2 egress pass and the
same-host peer connect returns RC=0 with no wedge and no step-timeout.

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

…#542)

Land the deferred OwnIp DNS registration and align host->PTask routing
with the DM2 topology in networking-with-diagrams.md (the daemon is not
on the gvproxy switch).

An OwnIp PTask now registers its hostname on launch, resolving to
127.0.0.1 (like HostNet) rather than its switch IP: the PTask is reached
through a gvproxy-published loopback port (its forwarder binds
127.0.0.1:<external> -> lease:<internal>, the same mechanism static
ingress uses), so the host-side proxies never need switch access and no
CAP_NET_ADMIN is required. The client selects the published external
port; the registry gates only on the host.

- dns: add register_own_ip (-> 127.0.0.1); rewrite the module doc from
  the switch-IP model to the published-loopback model.
- sessions: register OwnIp hostnames on launch and follow renames, in
  addition to HostNet (NoNet still registers nothing).
- proxy: replace the own_ip_routes_to_its_switch_ip test with
  own_ip_routes_to_its_published_loopback_port.

Verified end-to-end on DM2 native: with an own-IP PTask publishing
:8080 via ingress 18080:8080, a host request to
web.local.min.internal:18080 through the :7654 proxy reaches the
in-sandbox listener (host -> proxy -> gvproxy forward -> lease:8080).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

A session is tmux-like: detach (ctrl-w) or an abrupt client disconnect
holds the shell and its network open; only the shell exiting (or an
explicit kill/destroy) tears the network down. Add two session-host
tests over a recording NetGuard to lock this in:

- exit_releases_the_network: the shell process exiting drives
  net_guard.teardown() in the host mainloop.
- detach_keystroke_holds_the_session_and_network: a ctrl-w keystroke is
  swallowed as a detach signal (not forwarded, not fatal), the shell
  keeps running, and the network is only released on a later kill.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…ished port

The e2e harness now treats a session like tmux: it DETACHES (ctrl-w)
between assertions instead of sending `exit`, so a session's shell and
its own-ip lease stay alive and stable across the multiple attaches a
test makes (killing the per-attach lease churn and letting a
backgrounded in-session server survive for host-side curls). Also:

- unprivileged ports only (:8080): the sandbox has no
  CAP_NET_BIND_SERVICE, so `socat TCP-LISTEN:80` fails with EACCES;
- per-call nonce markers, since reattach replays screen state that may
  still show a prior call's markers;
- drop the flaky inline `proc ready` blocks for the reliable
  run_in_session path.

TC3 (UC2a) now reflects the published-loopback model: activate with
--ingress 18080:8080 and reach the service BY HOSTNAME at
web.local.min.internal:18080 through the :7654 proxy. Status table and
per-TC notes updated to the verified DM2 results.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…/R3.3/R4.4)

Resolve the contradiction between the normative requirements (which said
an OwnIp hostname resolves to its gvproxy switch IP, reached via the
switch) and the DM2 topology in networking-with-diagrams.md (daemon not
on the switch; host->PTask via gvproxy-published 127.0.0.1 ports) in
favour of the published-loopback model:

- R3.1/R3.3: an OwnIp PTask resolves to 127.0.0.1 and is reached through
  its gvproxy-published loopback port (R2.3), not the switch IP.
- R4.4: the mTLS reverse proxy forwards to the published loopback port.
- Proof Artifact 2 (UC2a) now curls the published port by hostname.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>