fix: reconcile a dead pin against declared evidence, not a branch guess (SYD-273)

[seanperkins]

Two changes aimed at the same loop: SYD-108 accumulated 8 redeliver_requested events over 15 days, each answered by a byte-identical delivery_failed, two of them 25 minutes apart.

1. The closed-pin reconcile asks the tracker before GitHub

SYD-232 added a replacement-PR check but scoped it to gh pr list --head agent/<ref>. That asks where work lives rather than what delivered it, and it's wrong for precisely the case that produced this bug:

• #61 — agent/SYD-108, closed unmerged (the pin)
• #124 — feat/syd-108-gate-delivery-events, merged aea0dd671377, titled "fix: gate delivery-events against agent actors (SYD-108)"

The branch query can never see #124, so every retry reported "no later merged PR" about work that had been on main for 15 days.

The authorization now carries deliveredByPrNumber: the issue's proof-bearing declared link joined to a merged pr_state row, on whatever branch.

Deliberately not sourced from gh_pr_merged events, which is what the issue proposed. This value makes the worker record delivered and mark the attempt merged_deployed — it declares the work shipped. That has to meet the SYD-280 evidence bar (a declared link) rather than the SYD-280-rejected one (a ref someone typed into a PR title). attention.ts puts it plainly: "clearing a delivery failure re-authorizes an actual merge+deploy, so the evidence has to be a declared link joined to an observed merge."

pr_state has no merge-SHA column, so GitHub still supplies the SHA — but as a targeted lookup of one known PR, not a search. The branch query stays as the fallback it was written for: a re-dispatch reusing agent/<ref>.

2. redeliverIssue refuses a pin that already dead-ended

The poll is a pure function of the pin, so an identical pin can only produce an identical answer. Re-running it costs a GitHub round-trip and re-asserts "work never landed" on an issue whose work is on main.

Gated on the pin being CLOSED, so the guard can't become a wall — reopening the PR is exactly the case where retrying the same pin is right, and pr_state knows when that happened. A moved head is a different pin and was never the doomed one. Both are covered by tests that assert the retry still goes through.

The refusal names the exits rather than just saying no: declare the PR that actually carries the work (the tracker then reconciles on its own), or resolve-delivery with a note.

Worth flagging: this does not fix SYD-108 by itself

I checked before building, and SYD-108's links are #61 delivers (the closed one) and #186 references. PR #124 is not linked at all, so getMergedPr returns null and deliveredByPrNumber will be null for it.

That's the real root cause, and it's upstream of this check: SYD-108's work landed through an interactive feat/ branch and nobody declared the link — the gap SYD-280 exists to close. Declaring #124 as SYD-108's delivers link is what unblocks it; this PR is what stops the next one happening. Both failure messages now say the declared-link path was checked, so "no PR on the branch" can't be misread as "we only looked at the branch".

Also

Repo comparison in the new guard is case-folded, matching the pr_state readers — suggestion 2 in the issue. Worth noting it's live in the data: SYD-108 records the merge under MobilityLabs/switchyard and its pins under mobilitylabs/switchyard.

Verification

npm test 2044 passed / 167 files · npm run typecheck clean · eslint + prettier clean.

Two existing tests needed updating, both mine to break: the /delivery-work exact-shape assertion (additive field) and the dead-end comment wording. I tightened both rather than loosening them — the deliver test now also asserts the message mentions the declared-link path and the declare-the-real-PR exit.