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

## What

§E ("you are the implementer") ends by forbidding the terminal
transition — neither `QA passed` nor an internal `Resolve` — until a
second pair of eyes has acknowledged the work. It says nothing about the
case where the person directing the session explicitly instructs both
the self-QA and the close. This PR adds that branch.

## Why

The gap surfaced in a live session on NRS-4596. The session owner
instructed "selbst QA" and "Ticket abschließen". User instructions
outrank skill rules, so complying was correct — but §E offers no
guidance for it, so it was handled ad hoc: the ticket was resolved and
the missing four-eyes recorded as `(!)` in the QA comment, while the
reply never mentioned that §E forbids exactly that step. The person
giving the instruction therefore had no chance to notice they were
overriding a guard.

## How

Comply, but name the override in the reply and mark it `(!)` in the QA
comment — silent compliance is the failure mode, not the transition
itself, because it leaves a Resolved ticket that looks reviewed. The
loophole is closed in the same paragraph: the instruction has to name
this step; a general "get it done" or an approval of unrelated work is
not authorization to self-resolve.

Docs only, one paragraph in `references/edge-cases.md`. No version bump
— that belongs to the release flow.

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.