test(e2e): fix the three firecracker tests that never ran

[Shine-neko]

Adding the Firecracker suite to the default set (#204) meant running it for the first time. Three of its nine tests failed. All three are test bugs — the runtime code is correct in each case — and each had been broken for weeks without anyone noticing, precisely because the suite never ran.

t2_ports died before doing any work. ip link show | grep -oE 'ring-…' exits 1 on a host with no ring-* tap, and set -e killed the test there. setup.sh and t4_restart.sh already guard the identical pipeline with || true; this one was written without it.

t3_api_instances read instances through deployment list --output json. The endpoint only resolves .address when asked with ?instances=true — an opt-in added in c071bdd (29 June) to avoid a per-instance runtime inspect on every listing, and the CLI never passes it. The test predates that change by three weeks, so it had been asserting against a field that is null on every runtime. It now queries the API directly.

Its second case asserted that a deployment without ports has no address. That encoded the pre-55ba04b behaviour; since 24 June this runtime allocates a tap for every microVM ("a microVM needs connectivity to be useful regardless of whether it publishes a port"), and ports only decide whether inbound forwarders are spawned. The assertion is inverted to match, with the reasoning recorded in place.

t8_job_kind booted its VM but never saw it complete. The CI rootfs ships with needs_recovery set, and debugfs writes straight to the block device without consulting the journal — so the kernel replayed the journal at mount and overwrote the injected systemd unit. The symptom was far from the cause: systemd logged Wants dropin … unreadable, ignoring: Structure needs cleaning, the unit never ran, the guest never rebooted, and the job sat in running until the 180 s timeout. Fixed by replaying the journal with e2fsck -fy before injecting.

Verified

Ran on a host with firecracker, /dev/kvm and CAP_NET_ADMIN on the test binary. All 9 tests pass, where 6 did before. 779 unit tests still pass.

This is the first real-runtime validation of the six micro-VM PRs merged this week — until now they were reviewed and unit-tested, but their boot paths were never exercised. Worth noting what the run confirmed along the way: the tap-collision guard reports the exact remedy, a failed boot classifies as retryable and climbs toward its restart bound rather than looping forever, no tap leaks across repeated failures, and instance addresses resolve to the expected 10.42.x.y/30.