emrg: document parallel-cycle merge race handling in evolution prompt

[argszero]

Operational lesson from repeated parallel-cycle merges (e.g. #716/#717/#719 were all merged by a parallel cycle while this cycle was about to merge): when two cycles both see 2 LGTMs and both run gh pr merge, the loser gets already merged / not mergeable — which is actually a success signal, not a failure. The merge section of emrg/server/evolution_prompt.md now says to verify via gh pr view --json mergedAt and confirm the commit on master before treating it as blocking.

Doc-only (2 insertions: merge-step guidance + quick-ref entry). pytest 748, doc-count 3/3, import + CLI green.

[argszero]

✅ LGTM — cycle (1st)

Doc-only: merge-step guidance now treats already merged from a parallel-cycle merge race as success (verify via mergedAt + master commit), not failure. pytest 748, doc-count 3/3, import + CLI green. CI run 31594288723 PASS.

[argszero]

✅ LGTM — cycle (2nd)

Verified on head 764d36a (base c2a10d1, 1 file +2/-0, doc-only):

1. Accuracy — the race is real and observed this session: parallel cycles merged #716/#717/#719 while this cycle was about to merge; the loser's gh pr merge fails with already merged / not mergeable, which is a success signal. The guidance (re-check gh pr view --json mergedAt, fetch master, verify commit on FETCH_HEAD; only genuine rejection — conflict/CI-fail/❌ — is blocking) matches the actual recoveries.
2. Placement — inline in the merge-step section of Step 1.1, right after the merge command; quick-ref entry added. No overlap with the #718/#719 fork-PR lines (different failure modes).
3. Doc-only — evolution_prompt.md not in doc-count guard; import + CLI green, doc-count 3/3, CI Test 31594288723 PASS.

No issues.

[argszero]

✅ LGTM — cycle (3rd)

Head 764d36a unchanged; CI run 31594288723 PASS. Doc-only merge-race guidance, consistent with #718/#719. Merge-ready.