configs: make the firmware filesystems actually readable (squashfs xz/lzo/lz4/zstd, xattrs, UBI/UBIFS, erofs)

[lacraig2]

Started as one line (squashfs xz) and grew into an audit of the same question across the
rest of the firmware filesystems: the filesystem being enabled says nothing about which
images it can actually read. Each commit stands alone and can be dropped.

The original gap

Both kernel lines ship CONFIG_SQUASHFS=y with no decompressor beyond zlib, so a guest
mounting a squashfs 4.0/xz image gets:

Filesystem uses "xz" compression. This is not supported
mount: mounting /dev/loop0 on /sqfs failed: Invalid argument

Measured on penguin v3.1.7, mipseb, on both 4.10 and 6.13. 6.13 prints the same line
without the squashfs: prefix, which is why grepping a console log for "squashfs" misses it
there. Loop devices are fine — loop0 is created, capacity is detected, the whole probe
list runs. Only the decompressor is missing.

xz is the dominant squashfs compressor in firmware. The case that fails hard is firmware
holding a nested squashfs inside its own rootfs and loop-mounting it at boot — common in
switch and AP images built around a kernel-embedded initramfs. There the mount fails, every
symlink into the mount point dangles, and no service starts. It is also expensive to
diagnose: from downstream it does not look like a kernel-config problem, it reads as a
broken extraction, and the extractor gets blamed first.

Commits

	change	evidence
1	SQUASHFS_XZ on both	measured, above
2	SQUASHFS_LZO, _LZ4, _ZSTD (zstd 6.13-only — squashfs gained it in 4.14)	none; the rest of the set
3	SQUASHFS_XZ into the required contract	the failure class the gate describes
4	SQUASHFS_XATTR + JFFS2_FS_XATTR	shipped kernels carry the Xattrs in filesystem, these will be ignored stub
5	MTD_UBI + MTD_UBI_BLOCK + UBIFS_FS on both	zero occurrences of UBIFS/ubi_attach/ubi_ctrl in either shipped kernel
6	EROFS_FS + _ZIP_LZMA/_ZIP_DEFLATE/_ZIP_ZSTD (6.13)	absent; the only EROFS hit is the errno in a jffs2 message

Two of these are worth a second look rather than a rubber stamp:

• Commit 3 widens required, which is otherwise scoped to IGLOO plumbing. The argument
  is that this is exactly the class the file documents — builds, links, correct ELF shape,
  boots, passes boot-check, then cannot mount the firmware it exists to run — and that
  all-common.inc is where one line fixes every cell and where one reshuffle can drop it
  for every cell at once. Only xz, not the other three.
• Commit 5 is the largest behaviour change. UBI is how NAND firmware stores a rootfs
  (squashfs on ubiblock + a UBIFS overlay), and today ubiattach cannot succeed on any
  target. Whether UBI attaches cleanly over penguin's MTD models is untested — but it cannot
  be tested at all while the kernel has no UBI.

Deliberately left out: MTD_UBI_GLUEBI (changes device enumeration everywhere; wants its own
change with a target behind it), EXFAT_FS (removable media, not a rootfs), and
F2FS_FS_COMPRESSION.

Verification

config-explain confirms fragment resolution for every new option across cells —
4.10/{mipseb,armel,x86_64} and 6.13/{mipseb,armel,riscv64,powerpc}:

$ nix run .#config-explain -- 4.10 mipseb CONFIG_MTD_UBI
  * CONFIG_MTD_UBI=y
      configs/4.10/all-common.inc:174
      via mipseb -> mips32-common.inc -> mips-common.inc -> all-common.inc

Every target chains to all-common.inc (directly or via an arch-common.inc), so one line
per version covers the matrix.

That is fragments only. I did not build the matrix locally — cross-toolchain builds here
run for hours. config-required, config-redundant and boot-check are CI's, and they are
the checks that prove an option survived olddefconfig into the shipped .config. The
dependency reasoning says every option here will: each depends only on its filesystem (or, for
UBIFS_FS, on MTD_UBI, which is why both lines are in the same commit), and the libraries
come in by select — XZ_DEC with its per-arch BCJ decoders all default y, LZ4_DECOMPRESS,
LZO_DECOMPRESS, ZSTD_DECOMPRESS, CRC16/CRC32 for UBIFS.

Not in this PR, but found while looking

HW_RANDOM and HW_RANDOM_VIRTIO are set on 6.13 and not on 4.10. 4.10 is the default
kernel for most firmware, so on that line there is no entropy source even when qemu attaches
a virtio-rng device — which is the shape of the getrandom()-wedges-a-daemon problem seen
elsewhere. Different axis from filesystems, so it belongs in its own change; flagging it here
because this is where it turned up.