fix(lba): check the address arithmetic the image chooses (2 fuzz-found panics)

[h4x0r]

Two fuzz-found panics, one defect

src/lib.rs:477:18  attempt to add with overflow   (parse_state)
src/lib.rs:596:26  attempt to add with overflow   (read_dir)

Both sites add a partition start to a logical block number, and both operands
are u32 fields read out of the image:

fsd_lba: partition_start + fsd            // File Set Descriptor location
let fe_lba = partition_start + icb_lbn;   // a directory entry's File Entry

Nothing bounded either, so a descriptor pair summing past u32::MAX panics.

The half that matters more

Release builds don't panic — they wrap. A wrapped LBA addresses a real but
wrong block, so the reader would report a confidently incorrect File Set
Descriptor, or a file size read from an unrelated sector. For a forensic tool
that's worse than a crash: a crash is visible, a wrong answer is not.

Fuzz builds enable overflow checks, which is why fuzzing found this and the
normal suite never could.

The fix

• FSD address — an overflow means the descriptor pair doesn't describe a
  location, so the walk returns Ok(None).
• Per-entry FE address — the entry is dropped and the walk continues; one
  unreadable FID says nothing about its siblings.
• Name-field bounds in the same block are header-derived too and now
  saturate, so an out-of-range span clamps and the existing id_end > id_start
  test leaves the name empty.

A trap worth recording

The first attempt used continue for the per-entry case. It read naturally and
hung the test suite: the loop advances off below that block, so skipping
the iteration left the cursor unmoved and spun on the same descriptor forever.
if let keeps the advance on the normal path.

Trading a panic for an infinite loop would have been a worse bug than the one
being fixed — and only running the test caught it.

Reproducers

The fixtures are the bytes libFuzzer actually found, taken from the failing
run's uploaded artifact rather than hand-authored, so they exercise the real
path rather than the one I'd have guessed. cargo fuzz tmin could not reduce
them: the size is what carries the offsets past the boundary.

They're kept as ordinary tests, not only as fuzz corpus — a defect found by
fuzzing shouldn't need fuzzing to be caught again. The fuzz job runs nightly;
the suite runs on every push.

Verification

• both reproducers pass through their real fuzz targets, not just the unit tests
• cargo test --workspace — 0 failures
• cargo fmt --all -- --check, cargo clippy --workspace --all-targets -- -D warnings — clean