feat: add buildfs/uploadfs — build and flash LittleFS/SPIFFS images from data/

[zackees]

Summary

fbuild has no way to build or flash a filesystem image. PlatformIO's buildfs / uploadfs targets have no fbuild equivalent, so there is no path from a sketch's data/ directory to an on-device filesystem.

Split out of #1354, whose original premise turned out to be partly stale: build-time .lnk resolution already exists. This is the actual remaining gap.

Verified current state

• No buildfs, uploadfs, --filesystem or equivalent anywhere in the fbuild CLI surface.
• .lnk resolution and materialization already exist: crates/fbuild-toolchain/src/lnk/mod.rs:1-22 documents scanner -> resolver -> materializer -> downstream build steps, and materialize.rs projects <src>/<rel>/foo.ext.lnk into <build_resources_dir>/<rel>/foo.ext.
• One consumer already exists: crates/fbuild-build-esp/src/esp32/orchestrator/embed_stage.rs:38-46 resolves .lnk entries named in board_build.embed_files and objcopy-embeds them into firmware.
• So the pipeline terminates at "materialized into the build tree" with no filesystem-image consumer.

Proposed

fbuild buildfs — assemble a filesystem image from the build-tree projection of data/:

• inputs = committed files in data/ union materialized .lnk blobs
• exclude *.lnk sidecars from the image (they must never ship to the device)
• invoke mklittlefs / mkspiffs per the environment's board_build.filesystem
• pre-check total size plus filesystem overhead against the partition size from the partition CSV, and fail at build time rather than at runtime mount

fbuild uploadfs — flash that image to the filesystem partition via esptool (already a dependency for firmware flashing).

Partition configuration — ci/boards.py in FastLED already has board_build_filesystem_size (unused) and board_partitions (used by two boards, both huge_app.csv). A default partition CSV reserving a filesystem region is needed for boards that want one.

Platform capability

buildfs is only meaningful where a flash filesystem exists:

Platform	Flash FS	PIO buildfs/uploadfs
ESP32 (Arduino-ESP32)	LittleFS, SPIFFS (legacy), FFat	Yes
ESP8266	LittleFS (SPIFFS deprecated in core docs)	Yes (plus uploadfsota)
RP2040/RP2350 (arduino-pico)	LittleFS only	Yes
Teensy 4.x	LittleFS_Program — runtime only, re-upload wipes files	No
AVR	none (1 KB EEPROM)	No
SD card, all platforms	runtime library, removable media	n/a — not deployable by a build tool

Selecting a filesystem target on AVR or Teensy should be a clear error, not a silent no-op.

Blocker

FastLED has no LittleFS backend. FsImpl is implemented only for Arduino SD over SPI, the WASM browser VFS, and a host stub. A littlefs image would be unreachable from FastLED's FileSystem API. buildfs should not ship pointing at an API gap — see the paired FastLED issue linked below.

Related

• feat: resolve remote example assets at build time (sha256-verified, globally cached) #1354 — original build-time resolution issue (narrow it to this)
• investigate: storage-target descriptors and misconfiguration diagnostics for .lnk / assets.json #1356 — storage targets and misconfiguration diagnostics
• research: normalize the .lnk format — two incompatible variants exist today #1357 — .lnk format normalization

[zackees]

Tracked in the meta issue: FastLED/FastLED#3986 — remote assets: hosting, build-time resolution, and on-device filesystem deployment.

[zackees]

Unblocked: FastLED/FastLED#3984 is merged, so fl::getEmbeddedFs() now exists and a LittleFS image would be readable from fl::FileSystem.

That was the stated blocker here — shipping buildfs without a backend would have produced images nothing could read. The remaining work in this issue (buildfs/uploadfs, partition config, mklittlefs/esptool wiring) is independent of it now.