Strike merge door can report fetch failure after merge and land the same head twice

[eltmon]

Incident

During PAN-2918 strike landing, the server reported Strike merge request failed: fetch failed for head d8ffa2b3d45990038ced2c9f6001b23b7379b4a7, but the same head was then merged twice:

• PR PAN-2918 #2919: created 2026-07-19T09:25:53Z, merged 09:36:55Z as ad90e27b85faac9210733711bf614276a4b6ebe5 with the full strike diff.
• PR fix(deploy): supervise patrol auto-deploy via systemd-run and break stale dead-pid restart locks (PAN-2918) #2920: created 09:38:36Z for the same headRefOid, merged 09:43:07Z as empty commit 2365ac7058f013b1040d4254e8fed7ce08cbe9c6 because the tree was already on main.

The recovery message was therefore emitted after the first landing had effectively succeeded, and the retry path did not reconcile that the marker head/tree was already on main before opening and merging another PR.

Required fix

1. After any merge-door transport/fetch error, reconcile the PR and current origin/main before marking the strike recovering.
2. Before every retry, treat the strike as landed when the marker head is already merged or its tree is already present through the recorded strike PR.
3. Add a regression test where the merge succeeds remotely but the client receives fetch failed; the landing state must become landed and no second PR may be created.

Related: PAN-2918, PR #2919, PR #2920.