[nmatt0]

Summary

Fixes a dead-code size guard in the romfs extractor. Closes #68.

The romfs on-disk size field (header offset 8) is 32-bit, so *size is a
uint32_t bounded at ~4 GiB. MAX_FILE_BYTES was 8 GiB, so *size <= MAX_FILE_BYTES
was always true and the guard did nothing. clang flagged it:

src/extract/romfs.cpp:84: result of comparison of constant 8589934592 with
expression of type 'unsigned int' is always true
[-Wtautological-constant-out-of-range-compare]

This was not a memory-safety bug (the following Reader::bytes is bounds-checked
against the image, so an oversized size reads nothing rather than over-reading).
The latent problem is resource use: the cap was meant to bound a single
allocation from a crafted size field, and it never fired.

Change

• Lower MAX_FILE_BYTES to 1 GiB. The value has to be representable within the
  32-bit size field to mean anything; 1 GiB is a generous ceiling for a read-only
  romfs file, whose whole image is already bounded to <4 GiB by the 32-bit
  full_size field.
• Clamp an oversized declared size to the cap and mark the result partial,
  matching how the ext/reiserfs/nilfs2 extractors handle an oversized size,
  rather than trusting the field.

Tests

tests/test_romfs_sizecap.py (wired into run.sh and ctest): builds a real
romfs with the bundled mkromfs.py, patches one regular file's 32-bit size field
to 0xFFFFFFFF, and checks that moria clamps it, reports partial, does not
crash (the ASan build is the out-of-bounds / allocation oracle), and does not
emit a multi-gigabyte file, while the intact sibling file still extracts.

The existing romfs round-trip in test_extract.py still passes, and the warning
is gone from the build.