Support additive FAT files via files_append

[jetm]

Problem

The device-tree-overlay feature needs to add compiled .dtbo files to a target's FAT boot partition at bundle time, but stone's manifest had no way to append files to an existing FAT image.

Solution

Add files_append support to the manifest so additional files are injected into a FAT partition image without redefining it.

Key changes

• manifest: support additive FAT files via files_append
• provision: bind guarded partition size with if let

Reviewer notes

Enabler for the Avocado device-tree-overlay feature (ENG-2134). meta-avocado's overlay delivery hook and the avocado-cli DTO commands build on this. First to merge in the stack: stone -> meta-avocado -> avocado-cli.

[jetm]

Cold second read of my own change. Draft, but posting rather than sitting on it - three of these mean the feature does not work end to end as described, and CI being green is consistent with all of them: every finding is either an unexercised code path or a case the 51 passing tests do not construct.

merge_fat_files itself is wired correctly. What is not wired is everything downstream of it - staging, validate, describe-manifest - and the --overlay path in front of it.

Eight findings inline. One more that could not be anchored because the file is not in the diff at all, which is itself the point:

src/commands/stone/validate.rs:181 skips files_append entirely. crate::manifest::BuildArgs::Fat { files, .. } => files.as_slice(), drops it, so validate neither checks that appended sources exist nor runs merge_fat_files (only called at bundle.rs:395 and provision.rs:214). A manifest with files: ["file_1"] and files_append: [{"in":"a.dtbo","out":"file_1"}], both inputs present, gets Validated. from validate and a hard failure from bundle. CI gating on stone validate learns nothing, and the "must surface at build time" property is absent from the one command whose whole job is checking a manifest before you build.

What I checked and found correct, so it does not get relitigated:

• Schema compat holds. A files-only manifest deserializes identically (pinned by test_fat_build_args_files_append_defaults_empty) and merge_fat_files preserves base order. The one exception is the duplicate-out thread below.
• Path escape is safe. add_file_to_fat (fat.rs:339-352) skips Component::RootDir and resolves .. inside the FAT volume through fatfs open_dir, so a hostile out cannot write outside the image file.
• 8.3 vs LFN is handled - fatfs compares both long and short names. I did not check FAT12/16 root-directory entry-count limits or path-length ceilings.
• Size overflow fails loudly, it does not truncate. Partition size is read before the merge (bundle.rs:388, provision.rs:263), and fatfs returns No space left on device from table.rs:310 via alloc_cluster (file.rs:271), which bundle.rs:418 propagates with ? before the copy at :422. No bundle is produced. Two diagnosability nits: the error is ErrorKind::Other with the detail only in the string, so callers cannot match on kind, and the message names the file rather than the overflowing partition.
• File ordering is deterministic - Vec order, base then append, no glob and no HashMap in the file path.

One pre-existing thing worth its own change, not this one: the image is not byte-reproducible. fatfs's DEFAULT_TIME_PROVIDER uses chrono::Local::now() (time.rs:137-150), stamped on every entry (dir.rs:410-413) and every write (file.rs:43-44), and the chrono feature is on transitively because Cargo.toml declares fatfs = "0.3" without default-features = false. So output varies with the builder's timezone, not just the instant. Fixable via FsOptions::new().time_provider(...) with a fixed-epoch provider. Lives in src/fat.rs, untouched here.

[mobileoverlord]

Concept is right and the implementation is careful. The fat_output_key normalization is the standout — fatfs resolving case-insensitively while create_file returns the existing entry without truncating is exactly the kind of thing that ships as a brick, and catching it at merge time rather than after the image is written is the correct place.

Verified locally against a Pi 5 style manifest: both overlays land in overlays/, the appended source is staged into the build dir (the bug that had provision failing a command later), the label reaches BS_VolLab, an identical re-emit collapses, and a case-variant collision aborts.

Pushed two follow-up commits rather than blocking on them:

• deny_unknown_fields is the right call, but Image being #[serde(untagged)] discarded the good diagnostic serde generates. unknown field \file_append`, expected one of ...was being collapsed todata did not match any variant of untagged enum Imageat a line number pointing past the mistake. Replaced the derived impl with a hand-written one that dispatches on JSON shape and propagates the object error verbatim. Also fixes any malformed image object — a droppedsize_unit` reported the same useless message.
• The literal [ERROR] in 18 error strings doubled against log_error's own prefix. Pre-existing, but this branch routes ordinary typos through that path, so it stopped being cosmetic.

Two things left for you, neither blocking:

• fat_label() is dead — bundle.rs and provision.rs destructure label directly from the variant. And fat_files_append()'s #[allow(dead_code)] is now stale since all_files() calls it.
• The strictness is still asymmetric. expnd for expand builds clean and silently gives you a non-expanding partition; blocksize for block_size likewise. Same failure class the deny exists to prevent, and arguably worse than a missing overlay. Worth extending to Partition/StorageDevice/Image in a follow-up with its own compat discussion.

Also worth adding deny_unknown_fields to the PR description — it's a breaking parse change for any manifest carrying a stray key, which isn't obvious from the title.