fix(review): never let an inconclusive linked-issue recheck downgrade a propagated label

[JSONbored]

Summary

• A merge-time (or later sweep/webhook) recheck of a PR's linked-issue label propagation could not distinguish "the recheck genuinely couldn't be verified this pass" (a transient GitHub fetch/rate-limit failure) from "the linked issue confirms no propagation applies" — both fell through to the blunt title heuristic and silently, permanently overwrote whatever correct label a prior pass had already applied.
• Confirmed live via server telemetry (Loki/Tempo/Prometheus on the self-host fleet): 118 PRs mislabeled across gittensory and metagraphed in a 2-day sample, 27 of them on the day this fix was written, all still wrong on live GitHub — including contributor-reported PRs feat(ui): check-run details-page readiness table (#2216) #4716 and Multi-tenant hosted architecture spec #4783. This reproduces (via a different trigger) the exact symptom the fix(review): merging a PR strips its propagated gittensor:priority/feature labels #4528 fix (merged 2026-07-09) targeted, which only closed the narrower "issue closed by this PR's own merge" race, not a concurrent-pass race or any other transient recheck failure.
• Fix, five parts (all evidence-grounded, see the #regression-safe-propagation doc comments in each file for the specific mechanism each one closes):
  1. linked-issue-label-propagation-fetch.ts: fetchLinkedIssueLabelsForPropagation now returns {labels, inconclusive} instead of a bare label list; isRepoMaintainerLogin distinguishes a confirmed permission result from an errored (inconclusive) one and logs the error instead of silently swallowing it.
  2. processors.ts: the type-label block now skips the mutation entirely (leaving existing labels untouched) when the recheck was inconclusive rather than confirmed-negative, and claims the existing per-PR actuation lock (claimPrActuationLock, already used elsewhere under fix(queue): concurrent webhook and sweep jobs for the same PR are not mutually excluded #2129) so two concurrent passes for the same PR can no longer race each other here.
  3. client.ts: excludes the two trust-deciding endpoint shapes (bare linked-issue reads, collaborator-permission checks) from cross-caller request coalescing, so one caller's transient failure can no longer become a different concurrent caller's answer.
  4. public.ts / rag-index.ts / grounding-wire.ts: three GitHub callers were computing their rate-limit admission key before a token fallback was applied (or never attributing one at all for a high-volume caller) — this is what buried the live incident in an unattributed key_scope="unknown" metric bucket instead of a diagnosable one.
• Does not touch the ~118 already-mislabeled PRs found live — those need a separate, deliberate backfill (like the 2026-07-09 83-PR backfill), not bundled into this code fix.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused — one root cause (an inconclusive-vs-confirmed-negative conflation in the propagation recheck, plus the three concrete rate-limit-attribution bugs that made it hard to diagnose), touching only the review-engine/GitHub-client code paths that chain to it.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves — this is a maintainer-authored fix for a bug found via direct production investigation (not a pre-filed issue); see Summary for the evidence trail instead.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally — 100% line/branch coverage on every changed line across all 6 changed source files (verified directly against coverage/lcov.info for the diff's exact line ranges, not just the repo-wide trend number)
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate — 0 vulnerabilities
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries — includes 3 end-to-end regression tests in queue.test.ts reproducing the exact PR feat(ui): check-run details-page readiness table (#2216) #4716/Multi-tenant hosted architecture spec #4783 race (inconclusive-skip-never-downgrades, lock-contention-skip, and a rewrite of a test that previously asserted the old buggy behavior)

Full npm run test:ci (all 27 steps, including test:engine-parity/test:driver-parity/the engine's own suite/test:workers/build:miner/test:miner-pack/rees:test/every ui:* check/ui:build) run twice end-to-end locally under Node 22 (per .nvmrc) with a clean exit both times.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. — N/A, no auth/session/CORS surface touched.
• API/OpenAPI/MCP behavior is updated and tested where needed. — N/A, no API/OpenAPI/MCP surface touched (ui:openapi:check confirms no drift).
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. — N/A, no UI changes.
• Visible UI changes include a UI Evidence section — N/A, backend-only change.
• Public docs/changelogs are updated where needed — N/A, no user-facing docs affected; changelog intentionally not touched.

Notes

• Root-caused via live Loki/Tempo/Prometheus telemetry on the self-host fleet, not source-reading alone — see the #regression-safe-propagation comments in each changed file for the specific confirmed mechanism (a Grafana alert/runbook that queries the rate-limit-responses metric by key_scope specifically depends on the "unknown" bucket staying visible for diagnosing exactly this class of bug in the future, which is why the metric-emission gating considered during development was reverted in favor of fixing the callers' own attribution instead — see the code comment on fetchWithGitHubRetry in client.ts).
• Follow-ups intentionally out of scope for this PR: (1) a fresh backfill correcting the ~118 PRs already mislabeled live, (2) deploying this fix to the self-host production engine.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.23%. Comparing base (9277537) to head (4d600ca).
⚠️ Report is 12 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4816   +/-   ##
=======================================
  Coverage   94.22%   94.23%           
=======================================
  Files         441      441           
  Lines       38745    38766   +21     
  Branches    14106    14111    +5     
=======================================
+ Hits        36508    36530   +22     
  Misses       1577     1577           
+ Partials      660      659    -1     

Files with missing lines	Coverage Δ
src/github/client.ts	100.00% <ø> (ø)
src/github/public.ts	98.57% <100.00%> (+1.60%)	⬆️
src/queue/processors.ts	95.71% <100.00%> (+<0.01%)	⬆️
src/review/grounding-wire.ts	96.70% <100.00%> (-0.04%)	⬇️
src/review/linked-issue-label-propagation-fetch.ts	100.00% <100.00%> (ø)
src/review/rag-index.ts	93.86% <100.00%> (-0.04%)	⬇️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.