fix(ci): repair linked-client-pr gate — status-cap spam + dead PR-event trigger

[WiktorStarczewski]

Fixes two bugs in the Linked client PR ready gate: (1) it spammed the PR author with a failure email every 15 minutes once a PR's head SHA hit GitHub's per-(SHA, context) status cap, and (2) its PR-triggered path never actually ran.

Problem 1: status-cap spam

The Linked client PR ready gate (.github/workflows/check-linked-client-pr.yml) re-runs every 15 minutes on a schedule cron and fans out across every open PR carrying a Client PR: marker. On each run it POSTs a fresh linked-client-pr-ready commit status on the PR's head SHA.

GitHub caps each (commit SHA, context) pair at 1000 statuses. Any PR whose head SHA sits unpushed long enough accumulates 1000 statuses; the POST then returns:

422 Validation Failed: "This SHA and context has reached the maximum number of statuses."

The workflow deliberately doesn't swallow API errors (to surface a 403 from a missing statuses: write scope), so the 422 propagates to exit 1 → job failure → an email to the PR author every 15 minutes. This is currently firing on the long-lived PRs (#22, #23, #25, #27); newer PRs (#30, #31) pass only because they haven't hit the cap yet.

Fix

Two changes to set_status:

1. Idempotency guard — read the latest existing linked-client-pr-ready status for the head SHA and skip the POST when state + description are unchanged. This both stops the email spam and stops accumulating statuses toward the cap in the first place.
2. Tolerate the 422 — when a SHA has already exhausted the 1000-status cap (e.g. from before this guard existed), treat the "maximum number of statuses" response as non-fatal: the verdict is unchanged and re-POSTing is impossible anyway. Any other failure (notably a 403 from a missing statuses: write scope) still surfaces as a job failure, preserving the original safety intent.

Also routes the no-marker success path through set_status so it gets the same guards; target_url is now attached only when a linked PR is known.

Why target main

Scheduled (schedule:) workflow runs always execute the default-branch copy of the workflow file. The failing runs are all event: schedule on main, so the fix only takes effect once it's on main — hence this PR targets main directly rather than next. The file is currently identical on both branches.

Verification

• python3 yaml.safe_load — workflow parses.
• bash -n on the extracted run: script — no syntax errors.
• Unit-tested the new set_status against a mocked gh for all five paths: unchanged→skip, changed→post, no-prior→post, 422→warn-and-continue, 403→fail. All pass.
• Validated the idempotency jq against the real GET /commits/{sha}/statuses shape on PR fix(web-client): align NoteType enum discriminants with miden_client::note::NoteType #22's head SHA.

Second fix: gate never ran on PR events

While verifying, I found the gate job skipped on PR events entirely: the workflow triggers on pull_request_target but the job's if: guarded on github.event_name == 'pull_request', which never matches under that trigger. So the PR-triggered path — the whole reason pull_request_target was chosen, per the safety comment — was dead, and the gate only ever ran via the cron.

Fixed here by guarding on pull_request_target instead, so the gate now evaluates and posts linked-client-pr-ready on PR open/edit/synchronize as intended. The matrix's non-schedule branch already reads github.event.pull_request.number (populated on pull_request_target), so it needed no change.

Note on verifying both fixes: pull_request_target (like schedule) runs the workflow file from the base branch (main), not the PR's copy. So neither fix takes effect on this PR's own runs — the gate job here still skips using main's current definition. Both fixes go live only once merged to main; that's also why this PR targets main directly.