feat(unic-archon-dlc): /pr-review fans out once instead of iterating, and the summary discussion goes

Decided with the maintainer in a /grill-with-docs session on 2026-08-28, against
WI 42991. He accepted it knowing it changes
unic-dlc-pr-review.

Blocked by #433 — the fan-out needs the angle briefs before it can fan out.

The problem the maintainer raised

The Box posts a summary discussion that stays open, and the team reads it as noise. Three cures were
put to him and he rejected all three, which is what made the real answer findable:

• Keep it and resolve it at the end — still a comment, still noise.
• Move it into the pull-request description — the description is the maintainer's, and ADO caps a
  description at 4000 characters, so a 40-finding summary fails exactly when the review was most useful.
• Move it to a file on the branch — noise in the codebase, and an agent picks it up as if it were source.

Why the summary exists at all

It is not decoration. It is the iteration's state store. The Box reads the prior iteration's findings
back out of the summary body: line 165 parses prior findings from "the prior summary + inline markers",
line 355 says "the summary is the only surface a scoped finding ever reaches", and lines 363-365 say a
finding that fails to reach the summary "is invisible twice over… because the summary is where the next
iteration reads hashes back". Delete the thread as it stands and reconcile loses every scoped finding
between rounds.

What the research showed

• Matt's code-review keeps no review state at all — one shot: pin a fixed point, spawn Standards and
  Spec in parallel, aggregate, stop. No iteration counter, no completion criteria, no persistence. It has
  no state because it has no round 2.
• PStack's interrogate buys breadth the same way: "have three different models try to break a
  diff" — parallel, one pass.

The decision

Stop having rounds. Fan out once, over the angles from #433, then one human pass.

The summary thread exists because rounds are sequential and round N+1 must know what round N said.
Remove the rounds and there is no cross-round state, nothing to store, and no thread to post. This
removes the cost rather than relocating it: six review dispatches collapse into one, which is the
token complaint answered directly. It also dissolves the separate question of how to bound the loop.

The risk, stated plainly: the documentation-staleness criticals surfaced at iteration 6, on a settled
diff. One pass over an unsettled diff may not find them. That argues for one scheduled second pass after
the fixes land — not for six.

The fallback, if fan-out proves too shallow

An Azure DevOps pull-request property: a key/value store on the pull request, invisible in the UI. It
satisfies every constraint the three rejected cures failed — not a comment, not in the repository, not the
description.

Verified both directions on 2026-08-28, against PR 5807: a PATCH wrote unic-dlc.probe, a read
returned it, a second PATCH removed it, HTTP 200 each time. Two costs if it is ever needed:
az devops invoke cannot PATCH a json-patch body, so it needs curl plus the PAT the Consumer already
holds at ~/.unic-azure.json; and the property size limit is unmeasured against a 40-finding payload.
Measure it before relying on it.

Acceptance criteria

1. One review dispatch produces findings from every angle #433 defines. No iteration counter drives a
   second dispatch.
2. No summary discussion is posted. Inline findings still post, and a reader can still see every finding
   the run produced.
3. Nothing reads review state back from a comment. If a scheduled second pass exists, its inputs are named
   and they are not a thread body.
4. The <!-- unic-dlc-pr-review:iteration=N --> marker machinery is deleted rather than left inert, or the
   issue says why it survives.
5. ADR-0026 is amended. Its two-axis premise and its round-based reconcile rules both change.
6. A Consumer run shows the new shape working end to end — the bar is a marketplace install and a real run,
   never pnpm test.

Notes

The bound question this replaces had one measured answer worth keeping: a lower round cap was not
supported by the data. Iterations 3-5 produced 0 criticals but iteration 6 produced 4. Anyone tempted to
solve this by capping rounds instead should read that number first.

Reference any new ADR by slug, never by number.

Start with the unic-dlc-pr-review entry point and the angle briefs from #433, then read ADR-0026 to identify the round-based assumptions. Implement the single fan-out shape without summary-thread state or iteration markers, and verify it with a marketplace install and a real Consumer run rather than pnpm test.