fix: measure the install target's own capacity, not the devtmpfs holding its node

[otavio]

Closes #409.

The bug

ensure_disk_space() checked free space with statvfs(target), but every caller passes a device node — /dev/mmcblk0p2 for raw/copy, an MTD character device for flash, a UBI volume for ubifs. statvfs reports on the filesystem holding the path it is given, and for anything under /dev that is the devtmpfs the kernel sizes after available RAM. The check never once looked at the partition being written to.

Measured on a development machine — three very different devices, one identical number, and that number is df /dev:

                 lseek END        statvfs available
/dev/nvme0n1     2000398934016    3365040128
/dev/nvme0n1p1     535822336      3365040128
/dev/sda         15610576896      3365040128

$ df -h /dev
devtmpfs  3.2G  0  3.2G  0%  /dev

This confirms the diagnosis @je-s reached in #409. It also explains why the reporter only hit it after growing their partitions: the rootfs used to be smaller than devtmpfs, so the meaningless comparison happened to pass. At a 10 GiB required_uncompressed_size it no longer did.

The failure is symmetric, and the other direction is the more dangerous one: a device too small for the update is accepted whenever RAM happens to exceed the object size.

The fix

Device nodes are asked for their own capacity by seeking to the end, which block devices, MTD character devices and UBI volumes all answer with their size. That is portable in a way the ioctls are not — BLKGETSIZE64 is declared in terms of size_t, so its request number differs between 32- and 64-bit userspace while the kernel writes back 64 bits either way, and MTD and UBI would each need an ioctl of their own besides. Paths that really do live on a filesystem keep going through statvfs.

A second fix on the same line: the statvfs fields are c_ulong/fsblkcnt_t, 32-bit on the armv7 targets this runs on, so the product wrapped for any filesystem past 4 GiB and the u64 conversion came too late to help. Both operands are widened first now, and the count is taken in units of f_frsize rather than f_bsize, which is what f_bfree is expressed in.

Tests

Two unit tests cover the statvfs path and the rejection behaviour. A third sets up a loop device and asserts the reported capacity is the device's own 64 MiB and not devtmpfs's free space — it needs root, as creating a loop device does, so it is marked #[ignore] alongside the MTD tests that already are. Run under sudo:

test utils::fs::tests::device_nodes_are_measured_by_their_own_capacity ... ok

cargo fmt --check, cargo clippy --all-features --all --tests and the full suite (157 passed) are clean.

Left for later

copy and tarball mount a filesystem onto the target and write files into it, so the device's capacity is an upper bound for them rather than an answer — it ignores both what is already there and the filesystem's own overhead. Measuring those properly means a statvfs on the mount point once mounted, which is a change of its own. They are still far better off than measuring devtmpfs.