rust: native no_std FS-CRUD port (in-place add/write/delete over &mut [u8])

[adeepn]

Owner decision (2026-09-02, follow-up to the image-API scope question): the Rust port must eventually support working with the whole EEPROM from firmware, not only host-side tooling.

Track A (done separately): the image module drops from std to the alloc feature — a no_std firmware with an allocator can parse_image / build_image whole images.

Track B (this issue): a native allocation-free Rust port of the FS-CRUD core (src/jeefs.c) over a caller-owned &mut [u8]:

• AddFile (device.id insert-first, headerless-image claim), WriteFile, DeleteFile (auto-defrag), ListFiles, ReadFile, walker;
• no heap at all — same buffer-centric model as C (eepromops v2: ops table + context instead of POSIX fd #25 variant A);
• conformance locked to C mechanically: shared mutation vectors / golden sequences, NxN where applicable;
• requires amending the charter line 'FS operations stay in C/C++' in CLAUDE.md (owner-approved by this decision).

Not started until the alloc release ships.