0.3.2

feat(code-review): only dispatch the reviewers a change actually needs

Every lens read every change. A pull request of three documentation files still
booted a security sandbox, a reliability sandbox and an operability sandbox,
each spending six to ten minutes to report nothing — and a reviewer with
nothing to say either returns empty or invents something the judging pass then
pays to reject.

Files are classified coarsely (code, test, config, migration, docs, asset) and
each lens declares which classes it needs at least one of. Coarse on purpose:
the finer the classification, the more confidently it is wrong.

THE RULE IS DELIBERATELY ASYMMETRIC, and that is the whole safety argument. A
lens is skipped only on POSITIVE EVIDENCE that it has nothing to look at, never
because the classifier is unsure. Running a reviewer that finds nothing costs
money, which is the status quo. Skipping one that would have found something
costs a bug, and looks exactly like a clean review. Those are not comparable
mistakes, so every uncertain case takes the expensive branch — including a lens
nobody has classified yet, which always runs.

correctness is never skipped: any change to anything can be wrong, and that is
the one reviewer whose absence is a hole rather than a saving. At least one
lens always runs, so "we reviewed nothing" is not an outcome this can produce
quietly.

Decided in prepareCycle, which is both where the file list first exists AND
where runsTotal is written — so the progress denominator counts the passes that
will actually happen. Selecting anywhere later would mean a bar that promised
five steps and delivered four.

The skips are RECORDED with their reasons, and the tab says which reviewers
read the change and how many sat out. A reviewer that never ran finds nothing,
and nothing reads exactly like a clean bill of health, so the absence is stated
rather than left to pass for a result.

A rule rather than a model call, deliberately. A model would judge better and
would also be another unit, another failure mode and another bill before the
review starts — and its decisions could not be shown to the user as a reason
they can check.

The tests are mostly about what must NOT be skipped, which is where the risk
is: correctness under every input, the at-least-one floor, an unclassified
lens, a migration keeping every runtime reviewer, and one source file among
documentation keeping all of them.