…iting "landed" (#61)

The daemon used to classify a sub-agent result based ONLY on exit code:
exit 0 = "landed", non-zero/timed_out = "blocked". But the /land-and-deploy
sub-agent (Kimi / Claude / Codex) gracefully declines to merge in real
scenarios — failing CI, no PR found, pre-merge gate fails — and still
exits 0 (subprocess ran cleanly, verdict lives in prose).

Observed in production on 2026-05-19 (mitosis-control-plane release-queue):

  Queue says    GitHub reality
  PR garrytan#120 landed  OPEN, e2e failing
  PR garrytan#122 landed  MERGED ✓
  PR garrytan#124 landed  MERGED ✓
  PR garrytan#129 landed  OPEN, e2e failing

50% false-positive rate. The queue records are stuck on "landed" so
discoverQueuedRecords (which filters status === "queued") never re-fans
out for them — silently abandoned.

Fix: after the land sub-agent returns exit 0, ask GitHub for the
authoritative PR state. New helper `verifyPrMerged(prNumber, repoIdentity,
cwd)` runs `gh pr view <pr> --repo <owner/name> --json state -q .state`
and returns { merged: true } only on MERGED. Anything else (OPEN, CLOSED,
gh exited non-zero, repoIdentity unparseable) returns { merged: false,
reason: "..." } and the daemon writes "blocked" with a useful lastError.

The repoIdentity is parsed via a strict ^github.com/owner/repo$ regex
so a planted record can't sneak shell-specials through to gh — anything
that doesn't match the regex gets rejected before any subprocess runs.

Network/auth failures (gh exited non-zero) are reported as not-merged
rather than thrown — better to block the record and retry than crash
the daemon and leak the lock. The remediation for any blocked record
is the existing retryReleaseQueueRecord CLI.

Injection seam: opts.verifyMerged?: typeof verifyPrMerged so tests can
control the response. Defaults to the real verifyPrMerged.

Scope: pre-existing bug, not a regression from PR #57. PR garrytan#120 was
marked landed at 12:30Z on 2026-05-19, hours before PR #57's work
began. PR #57's deploy verification surfaced it by running through a
real PR (garrytan#129) with failing e2e.

Tests: 60/60 release-daemon.test.ts (5 new regressions covering the
production bug pattern, the happy path, network failures, identity
parsing, and the positive parse case). Full orchestrator suite: 1525
pass / 16 fail, all 16 pre-existing on origin/main (confirmed via
git stash).

Remediation for stranded records on production right now (PR#120,
PR#129 on mitosis-control-plane): once this lands, the daemon needs
manual revival of those two records. The retryReleaseQueueRecord CLI
only handles blocked→queued, not landed→queued. Suggest a one-shot
audit script or extending the retry CLI to support landed records
whose GitHub state disagrees. Out of scope for this PR.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>