EEFS_LibInitFS: detect pointer-arithmetic wrap on EEPROM offsets

[nurdymuny]

Summary

EEFS_LibInitFS() adds the EEPROM-loaded FreeMemoryOffset / FileHeaderOffset to BaseAddress with no sanity check. On a 32-bit flight CPU the unsigned addition wraps when the offset is high-bits set (0xFFFFFFFF from a corrupted EEPROM image or SEU flip), and subsequent writes through FreeMemoryPointer / FileHeaderPointer scribble on arbitrary memory.

Closes #10.

Fix

For each pointer-arithmetic, compute the sum in uintptr_t and compare against the base; if the sum is less than the base, the unsigned addition wrapped and we reject the EEPROM as EEFS_NO_SUCH_DEVICE — the same status the existing "invalid file allocation table" path returns.

Diff

 libraries/eepromfs/eefs_fileapi.c | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

Tests

• Manual: hand-built an EEPROM image with FreeMemoryOffset = 0xFFFFFFFF, mounted via the standalone driver on a 32-bit build; before the fix this corrupted heap on next EEFS_Create; after the fix the mount fails cleanly with EEFS_NO_SUCH_DEVICE.
• Same with FileHeaderOffset on a per-file entry.
• Normal (well-formed) EEPROM images still mount successfully — the wrap check only fires on actual wraparound.

Scope

The same shape exists in tools/eefstool/src/eefs_fileapi.c (the eefstool variant). Same fix applies; I left it out of this PR to keep the review small, happy to extend if you want.