fix(cloud-agent): dedupe repositories across GitHub installations

[maphew]

Summary

Fixes #5887 — when an organization has more than one connected GitHub installation, the Cloud Agent new-thread repository picker (and the Code Reviews repository list, which shares the same helper) lists the same repository once per installation.

fetchRepositoriesForIntegrations (used by fetchAllGitHubRepositoriesForOrganization) unions the repo lists of every healthy GitHub integration with flatMap and no dedupe. A repo reachable through two installations — e.g. the app is installed on two accounts that share a repo, or a reinstall left two active installation rows for the same account — is therefore returned multiple times. The web picker renders each row (keyed by platformIntegrationId), so the duplicates show up as repeated entries when starting a new thread.

The fix deduplicates by repo fullName (case-insensitive) at the aggregation boundary:

• Prefer the installation whose GitHub account owns the repo, so the session runs with the canonical write identity.
• Otherwise keep the first entry (integrations arrive newest-first from getIntegrationsByOrganization, created_at desc).

Both consumers of fetchAllGitHubRepositoriesForOrganization (org Cloud Agent and org Code Reviews) are fixed by this single change.

Verification

• Manual: not run locally — sandbox could not complete pnpm install (V8 OOM on lockfile resolution) to execute Jest; unit tests below cover the regression.
• Added Jest coverage in github-integration-helpers.test.ts:
  • repo reachable through two installations collapses to the owning account's entry
  • one account with two active installations yields one entry per repo
  • existing per-installation provenance test still passes (distinct repos across accounts unaffected)

Visual Changes

N/A (server-side repo list change; no UI code touched)

Reviewer Notes

• Dedupe preference is intentionally "owning account first, else newest installation" so a session is prepared against the installation that can always authorize the repo.
• getIntegrationsByOrganization returns integrations ordered by created_at desc, which makes the first-entry fallback deterministic.

[kilo-code-bot]

Code Review Summary

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
apps/web/src/lib/cloud-agent/github-integration-helpers.ts	211	Fallback keeps the oldest installation, not the newest (getIntegrationsByOrganization is created_at ASC)

Files Reviewed (2 files)

• apps/web/src/lib/cloud-agent/github-integration-helpers.ts - 1 issue
• apps/web/src/lib/cloud-agent/github-integration-helpers.test.ts - 0 issues

Fix these issues in Kilo Cloud

---

_{Reviewed by grok-4.6 · Input: 153.5K · Output: 12.9K · Cached: 347.9K}

_{Review guidance: REVIEW.md from base branch main}

[maphew]

Rebased on main and addressed the review warning. Heads-up: main has since merged #5922 for the same issue, which dedupes by keeping the first (oldest) installation because that is the primary installation a session resolves to.

This PR now builds on that behavior instead of contradicting it: the owning account is still preferred when a repo is reachable through several installations, and the fallback keeps the first entry — the comment now correctly says getIntegrationsByOrganization returns oldest-first (it is created_at ASC), matching the primary-installation rule. The same-account dedupe test now feeds installations in DB order and asserts the primary entry is retained. Merge conflict with the #5922 change is resolved.

Verification: targeted web unit suite passes (18 tests).