Show both checksums per file, beside the queue

[owenpkent]

Summary

The interface could say a job was "Verified" without ever showing why. The source checksum and the destination's — the claim this whole tool rests on — lived only in the CSV and the PDF, so the person deciding whether to reformat a card had to open a report to see the evidence.

The selected job's files now sit beside the queue: size, both hashes, and a doubled check for a copy that was written and read back. The queue becomes the rail and this is its detail pane, split rather than tabbed so the proof is visible at the same time as the job it belongs to.

Decisions worth reviewing

• head:tail, not a prefix (28F7:EA9B). A prefix alone cannot distinguish a matching pair from a near-miss that shares one, which is the only thing these two columns exist for. test_abbreviation_keeps_the_tail asserts it.
• mismatch when destinations disagree with each other. Every copy comes from a single read, so they cannot legitimately differ — showing the first and hiding the rest would bury a real finding.
• Green only when it has proved something: the pair agrees and all destinations agree. A file the engine called COPIED whose destination hash differs from the source gets no green.
• Tooltips carry the full values, every destination path, and any per-destination error. The abbreviation is for scanning; checking against a manifest needs all of it.
• Rebuild is skipped for the same job object. The panel hears about the selection on every progress event and would otherwise reset the table dozens of times a second.

Most of the 16 tests cover the cases where the claim is not clean, since those are the rows that must not be misread as verified.

On the left rail

The other half of the inspiration was a vertical job rail. I did not build one: this window already has a left rail (drives), and a second would be clutter rather than clarity. Making the queue the rail with a detail pane gets the same structure without it. Say the word if you want actual vertical job cards instead.

Screenshot tool

Two fixes it needed to document this honestly:

• A finished job with real structure, so the pictures show the pane working rather than inviting the reader to select something.
• A trailing progress sample. The rate is measured against the clock now, so a hand-built queue item had none and the throughput column rendered blank — a regression the committed images predate. Stamped immediately before each shot, because a sample older than the window reads as no rate at all, which made the figure come and go with however long Qt took to start.

All three README images are regenerated, since the layout they document changed.

Test plan

• tests/test_gui_file_list.py — 16 tests: abbreviation incl. tail-sensitivity, verified pair coloured, mismatched destination not coloured verified, destinations disagreeing say mismatch, failed file marked, tooltip carries full hashes, summary counts "verified 2 of 3 / 1 failed", no rebuild on repeat, waiting message still updates
• Full suite 516 passed, 3 skipped; ruff clean (extends the existing Qt B008 per-file ignore already granted to queue_view.py)
• Screenshots regenerate cleanly; real offloader-gui.exe launches and runs

[owenpkent]

Reviewed the new file model/pane, job selection wiring, checksum abbreviation, multi-destination aggregation, tooltips, and queue/file split layout.

Validation: 20 targeted file-list tests passed on this head and git diff --check passed. The full checksum and each destination's path/status remain available in the tooltip, and disagreement between populated destination checksums is represented explicitly instead of showing only the first result.

A verification-mode presentation concern is included in the private review notes under the repository's integrity policy. It concerns the evidence implied by the new indicator, not a change to the engine's copied bytes. No interactive desktop walkthrough was performed.