e2e: cover firecracker host-memory admission

[Shine-neko]

Firecracker gets coverage for host-memory admission — the only resource gate the project applies at all.

What was added

t16_insufficient_memory.sh — a deployment asking for 999Ti must be refused with a terminal insufficient_resources status, before any work is done.

A microVM reserves its whole memory at boot, so an unchecked over-ask fails the spawn with an opaque allocation error and crash-loops, burning a rootfs copy and a TAP on every attempt for RAM that is never coming back. check_host_memory prevents that, and it is shared with Cloud Hypervisor — but only CH had a test for it.

The assertions go past the status: no Firecracker socket exists, no rootfs image was copied, the count stops moving, and the status does not drift onwards to crash_loop_back_off. An operator filtering on insufficient_resources needs it to stay there.

A divergence found on the way

Firecracker reaches this state with restart_count = 5 — the over-ask is retried up to MAX_RESTART_COUNT before settling. CH's t23 comments that the count "must stay 0 (no spawn attempt, no crash loop)" for the same shared code path, but never actually asserts it, so that figure was never verified.

Nothing leaks either way (the check fires before any copy or spawn, which this test proves), and the status is terminal on both. So the test pins the real behaviour rather than the documented intent, says so explicitly, and the divergence is tracked on the board for whoever decides which accounting is correct.

Verification

Run locally against a real Firecracker setup. Firecracker e2e coverage: 9 → 16 across this session.