perf(desktop): stop the Projects fan refetching on re-entry and running after leave

[Maxwellimus]

Entering Projects fires a large fan: an exhaustive paginated relay enumeration (projects/repos/tombstones), five 2,000-event work-item queries plus assignment-operation scans, per-repo activity summaries, and a local-repository filesystem scan. Measured on a large community (101 issues / 258 PRs):

query	measured cost
work-items (5 × 2,000-event REQs + assignment scans)	3.5–3.9s
activity summaries	4.1s
repository activity	1.0–2.2s
local repository scan	1.7s

Two lifecycle bugs made the fan far more expensive than it needs to be:

• Freshness windows guaranteed a full refetch on nearly every re-entry (60s enumeration, 30s work-items/activity, 10s local scan) — i.e., the costs above were re-paid on almost every visit. Every local write path already invalidates its keys explicitly (issue/PR mutations, project creation, repo sync), so the short windows only served remote-actor freshness. Raised to 5m/2m/2m with a 30m enumeration cache: re-entries now paint from cache, and the fan re-runs at most every 2–5 minutes.
• Leaving Projects left the whole fan running, competing with the next surface's channel fetches on the same relay connection. AbortSignal is now threaded through the enumeration and assignment pagination loops (optional params — behavior identical without a signal), and leaving the surface cancels the work-items query. Deliberately NOT cancelled: the enumeration (the always-mounted sidebar projects section observes it and its 30m cache is valuable), repo snapshots and local scans (native work that can't abort — cancelling would discard the finished result and force the same clones again), and activity summaries (a single bounded request).

Abort behavior is covered by red-first unit tests on both pagination loops. Remaining follow-up (out of scope): the queries themselves want a relay-side aggregate instead of shipping thousands of events to compute counts client-side.

[Maxwellimus]

🤖 Comment from Maxwell's AI agent.

Adversarial-review findings addressed in the latest push:

• Reconnect auto-heal can now repair partial work-items results: work-items added to RELAY_PROJECT_QUERY_PARTS in relayQueryInvalidation.ts (with test). Previously a partial fan-out result could sit "fresh" for the full two-minute window after a relay hiccup.
• Cache key now includes repository addresses: attach/detach-repository flows change the fan-out inputs without changing project ids; keying on addresses prevents a pre-attach result from serving as fresh.
• Abort check after the eager fan-out (projectWorkItems.ts): skips the reduce work and avoids caching a result for a surface the user already left.

Tracked follow-up (deferred): the five eager 2,000-event queries are single bounded REQs that relayClient.fetchEvents cannot abort mid-flight — only the assignment pagination is abort-aware. Making individual REQs cancellable needs abort support in the relay client itself; out of scope for this PR.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Reviewed exact head 0f832387d7adc8bf7b9cae84e2029973793e6c51 against GitHub-stated base aeb741fd31044ec560d953b0986dec2e7e93e2c6 (merge base 24ec6a468ec9d0d425ee58fbfc4d416412c446ad). No blocking lifecycle or cache defect found. Overview leave cancels the work-item prefix without killing the sidebar-owned project enumeration, cancellation preserves prior cache and remains cooperative at pagination boundaries, repository-address keying closes attach/detach reuse, and reconnect invalidation covers work items. Focused abort/enumeration/reconnect validation passed 22/22; exact-head CI is green and the diff check was clean.