docs: state what each command needs as input

[Paururo]

The reference page is organised by format and the command pages document flags,
so nothing answered the question people actually arrive with: what exactly do
I have to prepare to run this. Each command page now opens with an Inputs
section covering the files it takes, what makes a run fail, and what is skipped
with a warning instead.

Every constraint is read out of the code, not out of existing prose.

What the sections cover

Page	Anchor
train	Inputs
predict	Inputs
classify	Inputs
split-fastq	Inputs
match	Inputs

input-formats.md gains a pointer to them, since it is the by-format view of
the same material.

The four that were worth writing down

These all produce output that looks perfectly reasonable when you get them
wrong, which is why they belong in the docs rather than in a validation error:

• classify with -i or --input-files yields one row per FASTA record. A
  200-contig draft assembly is therefore reported as 200 genomes, each typed on
  whichever markers happen to land on that contig, and none of them representing
  the isolate. --input-list aggregates a sample's contigs under one name.
• match pools its whole sample list into a single query. It merges every
  FASTQ from every row into one k-mer set and reports one best reference. It is
  the only command where a sample list does not mean one result per row.
• split-fastq calls a marker only above --min-alt-percent, 95 by
  default, so intermediate frequencies never reach the output. That is why mixed
  infections surface as fixed markers on incompatible lineage branches rather
  than as intermediate allele fractions.
• predict has no unknown class. A query from a lineage absent from the
  training set still receives the closest label the forest can find; only a low
  confidence and margin reveal it.

One code change

The split-fastq help text claimed -k "must be odd, between 11 and 31". It is
not enforced:

k=10  accepted
k=12  accepted
k=21  accepted
k=33  Error: k-mer size must be between 1 and 31, got 33

The text now describes what the code does and keeps the odd value as the
recommendation it always was. If the intent was to enforce odd values with a
lower bound of 11, that is a validation change and a separate decision.

Documentation builds clean under --strict; cargo test --workspace passes
74/74.