xm510: sysupgrade --archive from /tmp cannot fit at the board's mem=18M #2618

On an XM510 booted the way its U-Boot boots it (mem=18M first, which is also what makes load_xiongmai choose three VI buffers), a local-archive upgrade cannot fit when the archive is in /tmp:

No room to unpack /tmp/openipc.xm510-nor-lite.tgz in /tmp: needs 4170 KB, 3656 KB free.
Use 'sysupgrade --channel nightly' instead -- it streams and stages no second copy. Aborting.

check_unpack_room refuses cleanly, as designed: nothing is written and services are restarted. But it means no archive staged in /tmp can be installed on an XM510 at its stock memory split. That includes the WebUI's "install from a file", which hands its upload to --archive in /tmp. The archive (about 4.2 MB) and its unpacked images (about 4.2 MB) have to sit in the same tmpfs, and at 18M that tmpfs is too small for both.

Seen under emulation, not on a camera. The machine was qemu-hisilicon's xm510 (32 MB RAM), booting OpenIPC nightly-20261016-2a2e35c from flash. The cmdline started with mem=18M, and sysupgrade --archive=/tmp/openipc.xm510-nor-lite.tgz -z ran from an SD hook (qemu-boot/test-sysupgrade.sh --cmdline-prefix mem=18M). At the time of the refusal, free reported 15.3 MB total, 4.2 MB used, 4.8 MB free and 6.3 MB buff/cache. With mem=20M the same run passes.

Possible directions, none tried:

• With the archive on the SD card rather than /tmp, only the unpacked images need /tmp, which should fit. If that's the supported path on small boards, the refusal message could say so alongside --channel.
• An archive route that streams gzip -dc | tar and removes the .tgz before the images are needed, or one that writes each member as it is verified, would avoid holding both copies.
• The WebUI upload path could warn on boards where /tmp cannot hold the archive twice.

Needs confirming on a real XM510 before anything changes.