fix(proxy): make the pin-drift watcher self-resolving and key-aware (…

[viknesh-ai]

…#174)

META_PROXY_VERSION is already current — #175 moved it 0.7.2 -> 0.7.4, and 0.7.4 is meta-proxy-dist's latest release. The pinned Ed25519 key still verifies that release's SHA256SUMS, so the pin itself needs no change.

What is still broken is the watcher that filed #174. Its logic lived as inline shell in the cron workflow, where nothing exercised it, and four of its untested branches were wrong:

• The issue title embedded both version numbers and doubled as the dedupe key, so any version movement broke the match and opened a second issue.
• Nothing ever closed a resolved drift. meta-proxy pin drift — META_PROXY_VERSION (0.7.2) is behind meta-proxy-dist v0.7.3 #174 has asserted "pinned at 0.7.2" for days after the pin reached 0.7.4.
• Every mismatch was reported as "behind". A pin running ahead of the latest release is the more dangerous case — install 404s on assets that were never published — and it got the exact opposite advice.
• gh release list --limit 1 is newest-by-date, so a draft or prerelease would have us pinning users onto an RC.

It also never checked the signing key its own resolution text told maintainers to confirm. A rotated key is invisible to a version comparison; it surfaces as every proxy install --yes failing verification.

Move the decision into scripts/proxy-pin-drift.mjs with the gh and network calls injected, so the branches are testable offline. Titles no longer carry versions, an existing issue is retitled rather than duplicated, a resolved drift is commented and closed, and the pinned key is verified against both the pinned release and any release we are about to recommend.

The dedupe search still matches the old version-bearing titles, so the first scheduled run closes #174 rather than orphaning it. Verified against live meta-proxy-dist with gh stubbed: state=current, pinnedKey=true, closed #174.

[ruvnet]

Reviewed and verified against live data. Merging.

Your verification note is now stale in the best possible way, and that made a better test than you could run. It says state=current, pinnedKey=true, closed #174 — true on 2026-08-13. Since then cognitum-one/meta-proxy-dist shipped v0.7.5 (2026-08-18) while the repo still pins 0.7.4, so the drift this watcher exists to catch is now real.

I ran run() against the live registry with a gh shim that permits reads and hard-refuses every write (issue create|edit|comment|close|reopen), so nothing was mutated:

pinned=0.7.4 latest=0.7.5 state=behind pinnedKey=true → updated #222

Every branch that mattered fired correctly:

• classification: behind, not the blanket "behind" of the old inline shell — and the ahead path is separately covered by a named test.
• key check: it fetched and verified the real v0.7.5 SHA256SUMS against the pinned META_PROXY_SIGNING_PUBKEY_PEM → pinnedKey=true, and the generated body correctly says "a version bump on its own is sufficient" rather than raising a false rotation alarm.
• dedupe: it found the existing open meta-proxy pin drift — META_PROXY_VERSION (0.7.4) is behind meta-proxy-dist v0.7.5 #222 and issued issue edit + issue comment, not issue create. That is the meta-proxy pin drift — META_PROXY_VERSION (0.7.2) is behind meta-proxy-dist v0.7.3 #174 fix demonstrated on live state — and the version-free title is why the search matched an issue opened long after the watcher's own titles changed.

Test suite: node scripts/proxy-pin-drift.test.mjs → 31 assertions, 18 named cases, all passing, one per claimed bug plus the ahead/rotation/unreachable-asset paths. (node --test reports "1 test" because the file uses its own runner — CI invokes it the right way at ci.yml:162.)

Also composes cleanly with #195, which merged an hour ago: the new runner-coverage gate recognises scripts/proxy-pin-drift.test.mjs as reached via ci.yml's node <path> form, so this PR does not trip it. Verified against current main.

Follow-up, not yours to fix here: the watcher now correctly reports a real drift that this PR deliberately does not resolve — the pin itself. I'm bumping META_PROXY_VERSION 0.7.4 → 0.7.5 separately, on the strength of the pinnedKey=true evidence above.