Take the reviewer's variance baseline on 0.28.0, before any fix lands #501

Question

How many unic-dlc-pr-review iterations on identical code make a variance baseline, and what is that
baseline on plugin 0.28.0?

Why it runs now, before any fix lands

#485 is the one ticket on this map whose effect
is only visible against a distribution: it is a property of an LLM reviewer, not a defect with a correct
answer. Run 3 measured it once — 0 of 13 hashes reproduced, the axis split inverting 9/5 to 3/10 on a
byte-identical commit — and once is an anecdote.

The moment #486 changes synthesize, that
distribution stops being observable on this version. 0.28.0 is tagged and reinstallable, so the
measurement is not strictly perishable — but the model behind the reviewer is not frozen, so a replay in
three weeks is not the same measurement. Take it now.

What resolving this produces

• A number for N, which is #485's own open
  question, and the reasoning for it.
• N iterations of unic-dlc-pr-review run against the frozen input, with per-iteration counts recorded:
  findings per axis, hashes reproduced, reconcile's four counters, and which threads post touched.
• A line in the findings register.

The frozen input

ADO reactivates an abandoned pull request, and a fresh pull request can be opened from the same branch
with no thread history. A fresh one per replay pair is the clean experiment: reconcile reads prior
threads, so a pull request that already carries them is not iteration 1 of anything.

Not decided

• Whether each replay pair gets its own pull request, or one pull request carries all N iterations. The
  first isolates; the second is what run 3 actually did and is what the run-4 walk will do.
• Which target branch the replay pull requests use. Targeting develop puts N abandoned pull requests on
  the client's board.

Runs in parallel

This blocks #486 and nothing else. It needs no
human turn and no plugin change, so it runs while the six precondition fixes are being written.