Released rp2 images can move the filesystem when a release's image grows, emptying boards that update #388

The rp2 images on the firmware page (the Pico 2 and the Pimoroni Pico Plus 2 W, built with --modules all) go through the same autosize as a local build. When an image doesn't fit beside the board's default filesystem, build_mp.py gives the firmware the image's size plus headroom, rounded up to 64 KB, and gives the filesystem what's left. Each release builds in a fresh folder, so that size is worked out from scratch every time. A release whose image grows past a 64 KB step, or past the default region for the first time, gets a smaller filesystem at a new offset. Anyone who updates from the firmware page then boots to an empty filesystem and loses their files, secrets.py included. The release notes tell people to copy their files off first, but not that this release is the one that moves it.

It isn't hypothetical. Two RPI_PICO builds of the same module set a few days apart came out at 1,398,144 and 1,460,520 bytes, and autosize gave them 576 KB and 512 KB filesystems, although the second image fits beside 576 KB with 46 KB to spare. The Pico 2's all image already fills about 93 % of its 2,560 KB firmware region, by the figure in the small-flash guide, so a little growth puts it into autosize.

What a release should do instead: keep each board's filesystem size fixed across releases, and move it only in a release that says so. Concretely:

• Each rp2 row in scripts/release_firmware.py names its filesystem size, and the release build passes it as --keep-fs (rp2 builds: --keep-fs keeps a board's filesystem through a firmware update #386). An image that no longer fits then fails the release build instead of shipping a moved filesystem.
• Changing that size is a deliberate edit to the row, and the release notes for that release say, for that board, that the filesystem moves and the board's files must be copied off and put back.
• The firmware page lists each board's filesystem size, so people can check before they flash.

The esp32 rows have the same exposure through esp32_autosize, which grows the app partition and moves the filesystem after it. That probably needs the same treatment, whether in this issue or in one of its own.