[mikecerisano]

What changed

On exFAT, renameatx_np(RENAME_EXCL) returns ENOTSUP (errno 45). The old ASC MHL fallback claimed an empty ascmhl directory, then used a plain directory rename that could replace a different writer's empty directory if the claim changed between the check and rename. A deterministic test reproduced that replacement before this patch.

FAT-family volumes now claim ascmhl once, write through the pinned directory, and keep a durable BITMATCH_HISTORY_STATUS.txt record. Its completion line binds the exact initial manifest and chain bytes. BitMatch Check refuses incomplete, altered, or missing-status FAT histories before considering an adjacent report; a partial history cannot look complete after relaunch. Existing histories are never overwritten or deleted. The exclusive-rename path remains for other filesystems, with a final pinned-stage and byte check before reporting success.

The direct FAT manifest uses a distinct filename so removal of the status file cannot make a partial new history look like a legacy one. Exact AppleDouble companions created by macOS on exFAT are accepted only after bounded metadata validation. Malformed status filenames cannot traverse outside the history directory.

Local validation

• Deterministic old-code red regression: substituted empty directory was overwritten. New focused mounted-exFAT/MHL XCTest: 37/37 passed.
• Full engine: 183 XCTest executed, 20 expected opt-in skips, zero failures; Swift Testing: 186 tests in 34 suites passed, with opt-in cases skipped.
• Mac app: TEST SUCCEEDED, 1,226 logical tests passed (1,273 parameterized case runs), 14 skips, zero failures.
• iPad simulator target: BUILD SUCCEEDED.
• git diff --check clean.
• Pinned official ASC reference CLI (ascmitc/mhl at 0fb61f1e) accepted the completed real-exFAT sample: schema, C4, media verify and diff passed. It also appended a second generation on a disposable copy.

Limits

BitMatch Check deliberately rejects a chain later extended by another tool, because this status record binds the original chain bytes. The official ASC CLI can read and extend the history; read-only validation of extended chain lineage remains separate work. FAT32, physical drives, and sudden power loss are not validated here. This fixes a confirmed publication race; it does not establish the cause of issue #10 or justify a release claim on its own.