docs(anti-patterns): don't reason a verifier FAIL away without re-probing (#28)

## Problem

The reviewer anti-patterns cover copy-pasting the implementer's output
(#12) but not the subtler failure: running the verifier, getting a FAIL,
and **reasoning it away** as an "environment artifact" or "known
false-positive" *without re-probing*.

Prompted by an offboarding QA batch where a coarse verifier's `ad` FAIL
was nearly dismissed as a regex false-positive — a precise independent
re-probe surfaced a **live Domain-Admin account for a departed
employee** 10 days post-termination.

## Change

Expands anti-pattern #12 (one-line, no renumbering) with:
- a FAIL believed spurious is still a FAIL until a **precise independent
probe** disproves it — present re-probe evidence, not reasoning;
- the **sibling cross-check**: when QAing a batch, the outlier that
FAILs an identical probe while N-1 pass is a real finding, not noise.

Author: CybotTM

skills/peer-qa-review/references/anti-patterns.md

@@ -21,7 +21,7 @@ Things to flag in the implementer's comments. Each item below is `(!)` unless no
 
 ## Reviewer anti-patterns
 
-12. **Copy-pasting implementer's output** instead of re-running. This is not QA — this is *re-reading*. R-pillar checks require fresh output.
+12. **Copy-pasting implementer's output** instead of re-running. This is not QA — this is *re-reading*. R-pillar checks require fresh output. Subtler variant: **reasoning a FAIL away** — a verifier reports FAIL and you dismiss it as an "environment artifact" or "known false-positive" *without re-probing*. A FAIL you believe is spurious is still a FAIL until a **precise independent probe** disproves it; present the re-probe evidence, not the reasoning. Sibling cross-check: when QAing a batch, if N-1 items pass an identical probe and one FAILs, the outlier is a real finding, not noise. (Caught in an offboarding batch where a coarse verifier's `AD` FAIL was nearly dismissed as a regex false-positive — a precise re-probe surfaced a live Domain-Admin account for a departed employee.)
 13. **Inflating `(x)` to look thorough** — only use blocking severity when the ticket genuinely cannot resolve. Over-bouncing wastes everyone's time. (`severity.md`)
 14. **Reviewing in pieces across many comments** instead of one structured QA comment. Hurts auditability — pillars get scattered, the verdict is unclear.
 15. **Quoting the entire implementer comment back at them** in the QA comment — wastes space. Reference by date/author/section if you must.