Offline rootfs image build (without S3 CI assets)

Context

scripts/build-rootfs.sh was removed in #293 (see that issue for rationale). It had been kept as a "documented manual fallback" but had drifted into effectively dead code:

• It duplicated provisioning logic that now lives in scripts/guest/guest-config.sh.
• It omitted the CI-kernel workarounds applied on the squashfs path (iptables-legacy, static resolv.conf, Docker's DOCKER_INSECURE_NO_IPTABLES_RAW).
• It produced a finished ext4 image that the current coop setup flow (download CI squashfs → unpack → guest-config.sh → pack ext4) does not consume.
• It shipped no kernel, so it couldn't actually unblock a user cut off from the Firecracker CI S3 bucket.

Today, image creation depends entirely on the Firecracker CI S3 bucket being reachable and publishing assets for a recent enough Firecracker minor. If that bucket is unavailable, there is no supported way to build a rootfs locally.

What we'd want

A genuine offline / from-scratch image-build path, if we decide it's worth supporting. Requirements that the old script did not meet:

• Reuse scripts/guest/guest-config.sh (single source of provisioning truth) rather than duplicating package/tool installation.
• Apply the same CI-kernel workarounds, or document/provide a kernel where they aren't needed.
• Produce (or point coop setup at) an artifact in the shape the current flow expects, end-to-end.
• Provide a kernel as well, since the rootfs alone can't boot.

Decision needed

Whether an offline build path is worth the maintenance cost at all, or whether relying on the CI S3 bucket (with the existing older-minor fallback) is sufficient. This issue tracks that decision and any follow-up implementation.

Start by reading scripts/guest/guest-config.sh, the current coop setup flow, and issue #293 for the rationale behind removing scripts/build-rootfs.sh. Determine whether an offline path is worth maintaining and how it would provide the expected rootfs artifact and a bootable kernel. Done means a clear decision, followed by an end-to-end implementation only if the path is accepted.