fix(pivot): give the new rootfs its own tmpfs, sized from real RAM

[ananthb]

Found while trying to pivot a Raspberry Pi 3A+ (415 MiB) into a NixOS installer. The pivot never got as far as pivot_root.

The bug

The rootfs is extracted straight into --work-dir, which defaults to /run/xmorph/rootfs. /run is itself a size-capped tmpfs — 10-20% of RAM on a systemd host — so the new rootfs silently inherits a cap that has nothing to do with how much memory is free.

On that Pi, /run is 83 MiB:

$ xmorph build --image docker.io/library/debian:trixie
Error: build rootfs: layer 0: extract layer 0:
  write /run/xmorph/demo/usr/share/info/find.info.gz: no space left on device
$ df -h /run
tmpfs  84M  84M  0  100%  /run

Two things wrong beyond the failure itself:

• The error names a random file, so it reads like a corrupt layer rather than a sizing problem.
• It fills /run to 100% on a host that is still running. /run is where systemd, dbus and friends keep their sockets, so a failed build degrades the OS we were specifically trying not to break.

Why the existing check didn't catch it

internal/sysmem is written and unit-tested, but the only reference to it outside its own package was a comment in runPivot:

// Memory headroom: warn before we commit to the pivot.
// (sysmem usage will be wired through when M5's RAM telemetry is
// surfaced via the slog output — for now we just verify the file
// is readable.)

It also would not have helped if it had run: it compares the rootfs against MemAvailable (246 MiB on that host), not against the tmpfs cap (83 MiB). It would have approved the build that then failed.

That's the shape of the bug — the thing being measured and the thing that constrains you were never the same number.

Changes

• Mount a real tmpfs at --work-dir, sized explicitly. Default is MemAvailable minus a 10% reserve; --rootfs-size takes 512M/2G/50%; --no-rootfs-tmpfs keeps the old behaviour for operators who have already arranged storage. On that Pi the default is ~154 MiB instead of 83, and the budget is logged either way.
• Actually call HeadroomCheck, against the size we are about to mount, and refuse while the old OS is alive rather than OOM mid-extract. Sizing from MemAvailable rather than MemTotal is deliberate: the old OS still holds its memory, and an OOM kill is worse than an ENOSPC because the kernel picks the victim — on a small host as likely sshd as xmorph.
• Report the tmpfs budget in the build rootfs error, since ENOSPC there is now a sizing decision the operator can act on.

Two follow-on fixes this exposed:

• os.RemoveAll(WorkDir) fails with EBUSY once WorkDir is a mount point — hit live once the tmpfs existed. Replaced with rootfs.CleanTarget, which empties the directory instead of unlinking it. That is also the operation the callers actually wanted: an empty target, not a deleted one. A reused mount is now cleaned too, so an aborted run cannot layer two rootfses together.
• Prepare's self-bind is skipped when the new root is already a mount. It exists only to satisfy pivot_root's "new_root must be a mount point" rule, and stacking a second mount to re-satisfy a rule that already holds just adds a mount to unwind.

Verification

Verified on the Pi:

• The bug itself — xmorph build into the default work dir dies with ENOSPC at exactly the 83 MiB /run cap, and fills /run to 100%.
• os.RemoveAll(WorkDir) fails with EBUSY once the work dir is a mount point (this is how that second bug was found).

Verified off-host: cross-builds clean for linux/arm64, gofmt clean, new unit tests for the size parser and the recommendation.

Not yet verified on hardware: the post-fix success path — a full extraction into a correctly sized tmpfs. That run was interrupted when the test host rebooted, and I have not repeated it. The fix is therefore verified against the failure modes it targets but not yet against a clean end-to-end build. Worth re-running before merge.

Notes for the reprovision docs (not in this PR)

While reading the reprovision recipes against this host, three things stood out that the docs don't currently cover:

1. docs/reprovision/nixos.md needs ~2 GiB because it runs disko-install, evaluating nix on the target. A prebuilt-image recipe — pivot into Alpine, then curl image | zstd -d | dd of=/dev/disk — needs ~50 MB, because nothing is evaluated or held in RAM. That is a different shape from "run an installer" and it is the one that fits small hosts.
2. The watchdog inverts during a reprovision. Normally it is the safety net: reset, boot the old OS. When you are overwriting the boot device, a reset mid-write is a guaranteed brick.
3. CleanupOldRoot uses MNT_DETACH. Lazy unmount does not release the block device, so writing to the underlying disk risks writeback from the old filesystem landing on top of the new image. That path wants the blocking UnmountOldRoot.

Also a small one, unrelated to this change: unmountUnder matches with strings.HasPrefix(m, oldRoot), so /mnt/oldroot-backup matches /mnt/oldroot.