perf(server): cache the open-PR lookup per worktree and branch

[Iaroslav (Rick) Postovalov (CommanderTvis)]

Every workspace activation asked the host for the branch's open PR/MR, and so did every window focus — and the host answered by shelling out to gh pr list, a round trip to GitHub measured at 430–560 ms per click, in front of ~20 ms of blocking git config/git remote probes on an event loop that runs git synchronously. Clicking between two worktrees re-queried both, forever, for an answer that changes only when someone opens a PR.

The lookup now remembers what it last answered, per worktree and branch, for 60 s, and concurrent askers share one in-flight call. A null is cached like any other answer: "no PR" is the common case and the expensive one to re-derive.

Two things invalidate an entry rather than letting it go stale:

• the repo-metadata nudge drops the worktree's entry, so a PR opened or a branch switched underneath converges on the signal that already refreshes the branch label instead of waiting out the TTL;
• openPr drops it on a successful outcome — opening a PR from the app is the one moment the cached answer stops being true without any git-metadata write to notice it, and without this the chip would keep reading "no PR" for the rest of the TTL.

Measured on the same host and repo, switching between two worktrees: the lookup falls from ~450 ms to 0, leaving git.status (50–70 ms) as the largest remaining per-switch cost.

Verification

check:deps, check:seams, lint, and typecheck pass.

Unit tests: 2 fail — pre-existing and environmental (git.test.ts forces a signing failure via gpg.program, which a machine configured with gpg.format=ssh ignores in favour of gpg.ssh.program, so the commit succeeds and the assertion doesn't hold).

The speedup is noticeable on my laptop.

🤖 Generated with Claude Code