fix(integrations): self-heal stale tokens in project-tracker adapters

[philluiz2323]

Summary

GitHubMilestonesAdapter and GitHubProjectsAdapter in src/integrations/project-tracker-adapter.ts minted installation tokens directly and passed them to Octokit with no withInstallationTokenRetry wrapper — unlike every GitHub-write helper in src/github/ (#6191). A stale cached token on any of the four real methods failed straight through (list → empty via caller catch; attach → hard fail) instead of self-healing.

Wraps listOpenMilestones, attachToMilestone, listOpenProjects, and attachToProject token+Octokit sequences in withInstallationTokenRetry.

Test plan

• test/unit/project-tracker-adapter.test.ts: 401-then-success retry for all four methods (2 token mints, 2 attempts each)
• Targeted vitest: 4/4 fix(integrations): GitHubMilestonesAdapter/GitHubProjectsAdapter never self-heal a stale installation token #9316 cases pass

Closes #9316

[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 75.43%. Comparing base (7dee222) to head (891b7e4).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #9391       +/-   ##
===========================================
- Coverage   89.46%   75.43%   -14.04%     
===========================================
  Files         836      276      -560     
  Lines      109609    58159    -51450     
  Branches    26103     6217    -19886     
===========================================
- Hits        98067    43875    -54192     
- Misses      10279    14014     +3735     
+ Partials     1263      270      -993     

Flag	Coverage Δ
backend	100.00% <100.00%> (+4.77%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/integrations/project-tracker-adapter.ts	100.00% <100.00%> (ø)

... and 698 files with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-27 16:04:03 UTC}

2 files · 1 AI reviewer · no blockers · readiness 98/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR wraps the four real GitHub calls in GitHubMilestonesAdapter/GitHubProjectsAdapter with withInstallationTokenRetry, mirroring the established pattern in src/github/labels.ts and closing the gap flagged in #9316/#6191. The refactor is mechanical (indent the existing body into a callback, return its result) and each of the four methods gets a matching 401-then-success test verifying exactly 2 token mints and 2 attempts, which is the correct way to prove the retry path is real rather than fabricated. One inconsistency: resolveProjectV2Fields (unchanged, used by #3185's field-resolution path) still calls createInstallationToken directly without the retry wrapper, so the self-heal gap remains open on that call.

Nits — 3 non-blocking

• src/integrations/project-tracker-adapter.ts: resolveProjectV2Fields (unchanged in this diff, ~line 191) still mints a token directly via createInstallationToken without withInstallationTokenRetry, leaving the same stale-token failure mode this PR closes for the other four methods — worth a follow-up or a one-line note on why it's excluded (it's not yet called in the live path per the doc comment, but it will be once feat(agent): promote project/milestone matching to auto-apply mode #3185 wires it in).
• The `// fix(integrations): GitHubMilestonesAdapter/GitHubProjectsAdapter never self-heal a stale installation token #9316: ...` comment is repeated verbatim four times in project-tracker-adapter.ts; consider stating the rationale once near the top of the pattern (e.g. on the first occurrence) rather than duplicating the full sentence at each call site.
• Confirm whether resolveProjectV2Fields is intentionally left out of this PR because it's not yet on a live call path, and if so note that explicitly in the PR description so a reviewer doesn't have to infer it.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#9316
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 992 registered-repo PR(s), 564 merged, 125 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	philluiz2323; Gittensor profile; 992 PR(s), 125 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
All four call sites (listOpenMilestones, attachToMilestone, listOpenProjects, attachToProject) are wrapped in withInstallationTokenRetry exactly as specified, preserving existing return contracts and error handling, and the PR adds regression tests for each method asserting a 401-then-success retry with a fresh token.

Review context

• Author: philluiz2323
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, JavaScript, MDX, TypeScript, CSS, Cuda, HTML, Kotlin
• Official Gittensor activity: 992 PR(s), 125 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.