--clump_only help text still says uBAM is rejected / a follow-up

[FelixKrueger]

Found during #391's code review (plans/08082026_clump-paired-report-preflight/CODE_REVIEW_B.md, out-of-scope observations): cli.rs:195 lists --output-format ubam among the flags rejected under --clump_only, and cli.rs:206 says "v1 is FASTQ in / FASTQ out only. uBAM in/out is a natural follow-up." Both predate the shipped uBAM arms and now contradict the docs site's clump-only page. User-facing --help text; two-line fix.

[FelixKrueger]

Fixed by #404 (squash-merged to dev as 90dda11). The whole four-paragraph block is now format-aware, plus the OutputFormat::UBam variant doc's two missing rejections.

The review round found more than the two claims this issue named. Most consequential: the fidelity claim. Making it format-spanning exposed that uBAM output is not byte-identical — bases are uppercased, IUPAC codes become N, and the space-separated header description is dropped, so a standard Illumina 1:N:0:INDEX field does not survive. Confirmed on a fixture: @READ_001 1:N:0:INDEX / acgtRYKM emerges as QNAME READ_001 / SEQ ACGTNNNN. The help text and the docs site (both its fidelity bullets and its intro) now say so. Also fixed: the uBAM-input constraint moved into paragraph 1, since that is the only paragraph -h renders; --preserve-tags documented as requiring a uBAM input (it is a hard error otherwise, not inert); and the paired clause now names multi-pair support and the two-separate-uBAMs rejection.

Follow-ups filed: #406 (the IUPAC warning states the wrong direction, and the uppercase/description-drop normalizations warn about nothing), #407 (--preserve-tags' own help still says "Ignored for FASTQ input"). Closing manually — merges into dev don't auto-close.