Fixes #7020

Description

Deleting a Project Group with "Remove contained projects" could leave the removed projects as stale, unusable rows in the sidebar until an app restart.

Root cause. The group deletion and each contained-project removal each emit their own repos:changed, and the renderer's repos.onChanged handler fires one unsequenced fetchRepos() per event. Those fetches race: an earlier fetch that read main-process state before the removals persisted can resolve last and overwrite the newer result, reintroducing the just-deleted repos into the in-memory store. A restart hides it only because startup reloads the final persisted state.

Fix. fetchRepos claims a monotonic reposFetchGeneration (held in slice state, mirroring the existing commitMessageGenerationRequestSeq / pullRequestGenerationRequestSeq convention) before awaiting, and drops its own set() if a newer fetch has superseded it while it was in flight. Only the latest fetch — the one started by the final repos:changed, which reads the final persisted state — applies. The generation is claimed synchronously before the await, so even a superseding fetch that later rejects still blocks the older stale fetch from resurrecting a removed repo.

Evidence

repos-stale-fetch.test.ts reproduces the race deterministically (a stale fetch that reads pre-removal state but resolves last):

• On main (bug present): both cases fail — the stale fetch's result wins and the removed repo reappears.

  - Expected  []
  + Received  [ { id: "local-repo" }, { id: "remote-repo" } ]
  Test Files  1 failed (1) · Tests  2 failed (2)
  

• On this branch (fixed): Test Files 1 passed · Tests 2 passed, and the full repo-slice suite is green (24 passed).
• pnpm run typecheck passes across all three projects; oxlint clean on the touched files.

ELI5

Deleting a folder-of-projects sends several "the project list changed!" pings. The app reloads the list once per ping, but the reloads can finish out of order — an old reload that still remembers the deleted projects can land last and paste them back. We now stamp each reload with an increasing number and ignore any reload that finishes after a newer one started, so the newest (correct, post-deletion) list always wins.

Trade-offs / regressions

• No regressions. The guard only ever drops a result that a newer fetch has already superseded; the newest fetch always applies. No public API, removeProject, or persistence path changes. reposFetchGeneration lives in slice state and no component subscribes to it, so it triggers no re-renders.
• Scope. The guard is deliberately limited to fetchRepos (the exact path in [Bug]: Deleting a project group can leave removed contained projects as stale sidebar rows until restart #7020's repro). The original revision also guarded fetchReposForAllHosts with the same counter, but a shared counter let an unrelated fetchRepos bump it and abort an in-flight all-host load, dropping every host's repos — so that guard was removed. The runtime-environment-active all-host path is therefore left at main's behavior (no new regression, and not part of the reported repro). Coalesce repos:changed refetch so stale fetches can't leave removed projects as ghost rows (#7020) #7083 (@xianjianlf2) proposed a coalescing-runner approach that would also cover that path and de-dupe the burst; credit to that framing for the broader-path analysis. This PR takes the surgical, store-level fix for the reported bug; the all-host path can follow up.

Credit

Original fix and repro by @AnddyAgudelo. Follow-up polish: isolated the regression test into repos-stale-fetch.test.ts (+ a superseding-reject case), moved the counter into slice state to match the repo's *RequestSeq convention, and scoped the guard to fetchRepos.