fix(ui): restore staged loading progress

Correct raw 1000:531e's Pascal-order BitBlt to destination (202,328), height 13, and width (stage-1)*7 from original DAT994. Render stages 2 through 35 over DAT995, add deterministic loading screenshots, and update the C harness and evidence ledger for the corrected 237x13 source.

Test Plan:
- bash original/tools/test_reconstructed_c.sh
- python3 original/tools/audit_reconstruction.py --require-complete
- cargo test --all-targets
- cargo clippy --all-targets --all-features -- -D warnings
- rumdl check original/C_RECONSTRUCTION_FINAL_AUDIT.md tdkpin-rs/CHANGELOG.md tdkpin-rs/RECONSTRUCTION.md tdkpin-rs/README.md
- cargo run --quiet -- --simulate loading --at 0.55 --screenshot /tmp/tdkpin-loading-mid.png
- git diff --check

original/C_RECONSTRUCTION_FINAL_AUDIT.md

@@ -78,6 +78,10 @@ ledger gates below still pass. Raw `1000:c79c` also confirms that the response
 reads fixed candidate slot 1 at `SS:...d8a2`; later nearer candidates are stored
 in subsequent 0x34-byte slots but do not replace the applied record. A focused
 two-candidate harness now seals that record-order behavior.
+Raw `1000:531e` further corrects the Pascal-order BitBlt interpretation: the
+DAT994 progress strip is drawn at `(202,328)` with height 13 and width
+`(stage-1)*7`, rather than the impossible historical 328x202 read from a
+237x13 bitmap. The focused loading-stage harness seals stages 1, 35, and 0.
 
 ## Reproducible gates