fix(storage): preserve long filenames safely

[Zartharas]

Summary

Preserve FatFs long filenames selected through Storage/Firmware Update instead of corrupting the fixed 32-byte backing filename buffer.

The original selection path copied into a 32-byte destination and then, for long names, wrote "..." at len - 4 using the source filename length. With a 38-character firmware filename, that offset is beyond the destination buffer; the same valid CRC firmware image was then rejected on-device as Invalid image file!.

This change:

• raises the ESP and firmware filename capacities from 32 to 256 bytes (FF_MAX_LFN=255 plus NUL)
• uses bounded copies with explicit NUL termination
• removes the out-of-bounds ellipsis mutation from the operational filename
• uses size_t for dynamic path-length accounting while preserving the callers' nonzero-success contract

Directory path capacity remains 64 bytes; this PR does not claim arbitrary deep-path support.

Validation

• Host ASan equivalent baseline: exact 38-character failing filename reproduced a stack-buffer-overflow (WRITE size 4)
• Patched ASan/UBSan: 38-character filename PASS
• FatFs 255-character filename boundary PASS
• Maximum constructed 319-character path PASS
• Paired Arm GNU 14.2.Rel1 baseline/fixed builds PASS
• Compiler warnings: 1075 -> 1075; build errors: 0 -> 0
• ELF text/data unchanged; BSS +224 bytes, exactly matching the static filename buffer increase from 32 to 256 bytes
• Canonical committed Linux/amd64 container build PASS
• Physical M1: exact committed firmware installed successfully
• Physical 49-character firmware filename: visible and selectable; no Invalid image file!; normal update confirmation reached
• Redundant second flash intentionally not performed after validation reached confirmation

Scope

Exactly three files:

• m1_csrc/m1_file_browser.c
• m1_csrc/m1_storage.c
• m1_csrc/m1_storage.h