[mikecerisano]

A 512 MiB ASC MHL reread made BitMatch's physical memory footprint grow by 511 MiB. On exFAT, that reread is part of a normal verified transfer because BitMatch cannot safely reuse the earlier readback evidence. A separate XXH64 Saved Check read had the same problem. Both reads now release each chunk's Foundation buffer after hashing it, while keeping the destination reread, file checks, progress, cancellation and no-overwrite history rules.

Measured before and after, using the actual engine paths:

• ASC MHL, 512 MiB sparse file: 10 → 521 MiB before (test fails); 10 → 10 MiB after (test passes). All 128 chunks were read; the manifest and chain were published.
• XXH64 Saved Check, 512 MiB sparse file: 5 → 521 MiB before (test fails); 5 → 9 MiB after (test passes). The deliberately mismatched checksum still reports the file as changed.

Run the isolated checks with BITMATCH_MHL_MEMORY_TEST=1 and BITMATCH_CHECK_MEMORY_TEST=1, respectively; exact commands and measurement limits are in docs/ISSUE23_MEMORY_AUDIT.md.

Other local validation: the mounted-exFAT Standard copy → verification → MHL handoff passes; the full serial engine suite passes (126 XCTest cases, 17 intentional skips, no failures; 151 Swift Testing cases pass); the Mac app test build passes (1,099 passed, 13 skipped, zero failed); and the iPad/iPhone simulator build succeeds. git diff --check is clean.

Related to #23. These are confirmed memory bugs, but the reporter has not yet supplied the app version, stage or diagnostics, so we cannot say which path caused the reported 55 GB footprint. The large memory tests use sparse APFS files; the separate mounted test covers the real exFAT driver with small media. Physical hardware and footage remain untested here.