docs(edge-cases): cover explicitly instructed self-review in §E

§E told the reviewer to stop before the terminal transition and said nothing
about the case where the person directing the session instructs the self-review
and the close anyway. That left the branch undefined, so it got handled ad hoc:
the transition was performed and the missing second pair of eyes recorded, but
the reviewer never named that §E forbids the step.

Add the branch explicitly — comply, because user instructions outrank skill
rules, but say so in the reply and mark it `(!)` in the QA comment. Silent
compliance is the failure mode, not the transition. Also close the obvious
loophole: the instruction must name this step, not be inferred from a general
"get it done".

Signed-off-by: Sebastian Mendel <github@sebastianmendel.de>

Author: CybotTM

skills/peer-qa-review/references/edge-cases.md

@@ -67,6 +67,8 @@ If your account appears in any of these, §E applies regardless of who the ticke
 2. **Flag for colleague**: post a follow-up comment / ping in the team channel asking for a real second pair of eyes.
 3. **Do not transition to the terminal verdict (neither `QA passed` (QA2) *nor* an internal `Resolve`)** until at least one other set of eyes has acknowledged the work, even if it's just a `(/)` from a colleague after the fact. The internal-resolve path is **not** an exemption: self-*resolving* your own work is the same self-review as self-passing it, and it closes the ticket with no second reviewer ever in the loop. Leave it in QA with the constraint documented until a colleague acknowledges; do not walk it to Resolved to "get it off the queue".
 
+**When the person directing the session instructs it anyway.** A direct instruction — "do the QA yourself", "close it" — outranks this guard, because user instructions take precedence over skill rules. Comply, but never silently: state in your reply that §E forbids the terminal transition on self-review and that you are proceeding on their instruction, and record the missing second pair of eyes in the QA comment as a `(!)` so the ticket carries it too. Silent compliance is the failure mode here, not the transition itself — it leaves a Resolved ticket that looks reviewed. The instruction has to be explicit about *this* step: a general "get it done", an approval of unrelated work, or an earlier close-out on another ticket is not authorization to self-resolve, and reading one into it is exactly the shortcut this section exists to prevent.
+
 ## F. The ticket should not have been put in QA
 
 Common signals: implementation was clearly aborted ("WIP, will continue Monday"), required pre-work isn't done (a dependency ticket is still open), the implementer ticks "ready for QA" while admitting in the same comment that something is missing.