Refresh reliability notes and remaining validation work

CHANGELOG.md

@@ -12,8 +12,11 @@ All notable changes to this project will be documented in this file.
 - Remote backups now claim a new filename before upload and recover only files BitMatch can still identify as its own. Existing remote files are left alone; unsupported server setups stop with an issue.
 - Cancelling a remote backup now stops the SSH work it started, including child processes.
 - Camera hints skip oversized XML metadata instead of loading it all into memory. This does not change the transfer file list.
-- The finish screen describes the checks actually performed and acknowledges files that did verify even when the transfer as a whole needs attention.
-- Keep copy and verification failures below 100% in live progress; the engine emits “Complete” only when all selected files pass the chosen mode. The final safety verdict still includes later ASC MHL and report steps.
+- Finish, History and reports separate the selected verification plan from the results actually recorded. Older checksum reports no longer get labeled as a mode they did not record, and unknown or conflicting checksum algorithms stay unverified. Partial results stay visible without claiming the transfer completed.
+- Interrupted exFAT copies leave a visible incomplete-transfer warning on the destination. Existing files stay untouched, and unfinished copies cannot earn a safe verdict.
+- Made saving ASC MHL histories on exFAT safer: unfinished or damaged histories stay unverified, and an existing history is never replaced.
+- Check can validate supported ASC MHL inventory chains, including intact histories extended by another tool, without rewriting them. Directory hashes and recorded renames remain unsupported.
+- Large clips now move progress as their bytes are copied and checked. Queue cards are weighted by estimated work, and the bar stays below 100% while reports and final transfer records finish. Failed or interrupted work never appears complete.
 - Ignore a disappearing root `.fseventsd` metadata directory during card scans without hiding ordinary files. A regular source file with that name now contributes to the source fingerprint.
 - Bound saved JSON, MHL and adjacent checksum-manifest reads during loading. Damaged, oversized, conflicting or empty adjacent records are reported instead of silently falling back to partial evidence, including when another companion looks valid.
 - Keep a retained remote verification timestamp from claiming a photographer card is fully backed up when its local evidence is rejected. Remote status labels distinguish downloaded readback from older server-checksum evidence, including backups with mixed evidence. Refreshing a saved backup no longer changes its completion time.

Packages/BitMatchEngine/Tests/BitMatchEngineTests/Fixtures/EvidenceCompatibility/README.md

@@ -14,7 +14,7 @@ The tests copy fixtures into disposable roots. MD5/XXH64, zero-byte files, Unico
 
 `reports/` captures current, older, extended, Quick, unsafe, unknown-method, unknown-algorithm and truncated JSON. Only current and compatible extra-field snapshots may supply a verified saved-report status. These handcrafted snapshots test reader compatibility; they are not fresh verification evidence or output attributed to an external offload application.
 
-October 14 additions use the same pinned reference commit and license: `sha1/` and `xxh128/` are valid external inventories that BitMatch must explicitly reject as unsupported, both alone and beside a readable history. `xxh64-boundaries/` contains original byte sequences (`byte[index] = index % 251`) of lengths 0, 1, 31, 32, 33, 255, 256, 257 and 1025, covering XXH64's lane and tail boundaries. These fixtures passed the independent checks below; the new Swift consumer regressions still require an Apple test run.
+October 14 additions use the same pinned reference commit and license: `sha1/` and `xxh128/` are valid external inventories that BitMatch must explicitly reject as unsupported, both alone and beside a readable history. `xxh64-boundaries/` contains original byte sequences (`byte[index] = index % 251`) of lengths 0, 1, 31, 32, 33, 255, 256, 257 and 1025, covering XXH64's lane and tail boundaries. These fixtures passed the independent checks below; their Swift consumer regressions also passed on Mac.
 
 October 17 addition: `md5-renames/` is another output of the same pinned reference CLI, generated with `create -h md5` and then `create -h md5 -dr`. Between those generations, one synthetic file is renamed and `Reel B` is renamed to `Reel C`. The second manifest records two file `<previousPath>` values and one directory `<previousPath>`; the reference verifier and diff accept the final folder, while a further unrecorded directory move fails. BitMatch Check deliberately rejects this history as unsupported until it can interpret rename lineage and structure. It does not call the old paths missing or claim to have verified the chain. The media payloads and fixture script are original/MIT; the reference-tool output retains its MIT notice in `ASC-LICENSE.md`.
 
@@ -24,11 +24,11 @@ Run the corpus checks on Linux or macOS without Swift, using the reference venv:
 python Scripts/ascmhl/validate_corpus.py /path/to/pinned/ascmitc/mhl
 ```
 
-The runner requires the pinned, unmodified checkout, uses its code and schemas, suppresses the CLI's online update check, and checks inventory/chain schemas, generation counts, C4 chain digests, bytes and paths. It checks changed, missing, renamed, extra, modified-manifest and missing-manifest cases only in disposable copies, requiring specific failure codes. A rename must report both the new and missing path. SHA-1/XXH128/C4 are verified by the reference tool here, not claimed as supported by BitMatch. Originals must remain byte-for-byte unchanged. `validate_reference.sh` runs this subset as well as the Apple-only freshly generated BitMatch workflow. The corpus-only runner is also a Linux CI job.
+The runner requires the pinned, unmodified checkout, uses its code and schemas, suppresses the CLI's online update check, and checks inventory/chain schemas, generation counts, C4 chain digests, bytes and paths. It checks changed, missing, renamed, extra, modified-manifest and missing-manifest cases only in disposable copies, requiring specific failure codes. A rename must report both the new and missing path. SHA-1/XXH128/C4 file hashes are verified by the reference tool here, not claimed as supported file digests by BitMatch. Originals must remain byte-for-byte unchanged. `validate_reference.sh` runs this subset as well as the Apple-only freshly generated BitMatch workflow. The corpus-only runner is also a Linux CI job.
 
 Generate just new datasets without replacing existing originals using `--datasets sha1 xxh128 xxh64-boundaries md5-renames`. Default generation creates all seven datasets. Generation suppresses the reference CLI's online update check as well.
 
-`classic-v1.mhl` is a handcrafted boundary fixture, not external-tool output. It is rejected inside an ASC history both alone and beside a valid reference history; standalone classic-MHL discovery is still unsupported. This batch does not claim full chain, rename or directory-hash verification. ASC checks explicitly describe their file-content scope. Histories are never rewritten by these checks.
+`classic-v1.mhl` is a handcrafted boundary fixture, not external-tool output. It is rejected inside an ASC history both alone and beside a valid reference history; standalone classic-MHL discovery is still unsupported. Check's supported inventory-chain scope is described below; directory hashes, rename lineage and historical authenticity remain outside it. Histories are never rewritten by these checks.
 
 
 October 19 addition: `reference/bitmatch-fat-extended/` is a **sanitized derivative** of the actual engine's initial FAT-v1 history generated by `ASCMHLFixture` on a disposable mounted exFAT image. The real mounted sample separately passed official extension/verification/diff with its original status unchanged. For the public fixture, the initial hostname was replaced with `bitmatch-fixture-host` and the synthetic clip filename changed to ASCII `Camera A/clip.txt`, and its exact v1 single-generation chain/status was rebuilt during fixture creation only. The pinned official `ascmhl create -h md5 -i '._*'` then appended generation two to that sanitized copy; this is not a byte-for-byte mounted-volume capture. The first media payload comes from the original/MIT fixture executable; `added.txt` is original synthetic text. The new reference output retains the ASC MIT notice above. The official CLI hostname is the synthetic `bitmatch-fixture-host`. Its explicit metadata pattern excludes only test-volume AppleDouble companions from this portable dataset; it does not define BitMatch's production filtering policy. No existing fixture was rewritten.