Collision pre-flight cannot name which input produced a colliding report

[FelixKrueger]

Follow-up from #391's reviews (recorded in plans/08082026_clump-paired-report-preflight/, confirmed live by both code reviewers): when two reports collide, io::preflight_output_collisions prints the same path twice —

Error: Output path collision (…): out/reads.fq_clumping_report.txt and out/reads.fq_clumping_report.txt would be written to the same file. … rename one input …

— because the candidate list carries no input provenance, so the message tells the user to rename an input it cannot name. The remediation works (the reworded hint's "inputs sharing a filename" narrows it), but naming the two source inputs would make it actionable directly. Fix shape: thread (PathBuf, source) pairs or a parallel provenance slice through the pre-flight. Applies equally to #388's trim-report site.

[FelixKrueger]

Fixed by #413 (squash-merged to dev). Collision refusals now carry provenance, so they can name the files you have to change.

Before: out/reads.fq_trimming_report.txt and out/reads.fq_trimming_report.txt would be written to the same file … rename one input — the same path twice, naming neither input.

After: the outputs named from a/reads.fq and b/reads.fq would be written to the same file, out/reads.fq_trimming_report.txt.

Four shapes: output-vs-input names the input its output derives from; two sources sharing one rendered path name both and print the path once; differing spellings (fold-equal, or ./x vs x) show both paths with their sources; and one input feeding two candidates gets its own advice. That last is new behaviour — --paired A.fq B.fq B.fq C.fq is permitted by validation and was refused with advice nobody could act on, since a file cannot be renamed apart from itself.

Design decisions, per the plan's C1–C4: shape 2c included (its old advice was unfollowable); uniform Pair for paired primaries so this could land before #398 is decided; Input(chunk[0]) kept for the clump paired-BAM report because R1 genuinely is the source there. C4 was split out as #409 and landed first.

Worth recording plainly: the tuple makes an unattributed candidate impossible but cannot detect a missing one — which is what #383, #385, #388, #391 and #409 all were. The durable fix for that family is one derivation feeding both the candidate list and the writers, or #391's exact-set assertion extended across all 11 pre-flight arms.

Closing manually — merges into dev don't auto-close.