fix(web): pull request panel polls go around the server's hold

[ylcn91]

What Changed

apps/web/src/components/pullRequest/PullRequestDetailPanel.tsx: the panel's automatic refresh (the five-minute interval, and the read on returning to the window) now invalidates the pull request on the server before re-reading its detail, the same way the Refresh menu action already does. The invalidation is scoped to that one pull request (bumpRefEpoch), so no listing, viewer, or other pull request is dropped with it.

Why

Fixes #8640.

The server answers an ordinary detail read from what it already holds and refreshes behind the answer (lastGoodDetail.serveHeld(..., "revalidate")). That suits reopening a panel, but a poll exists for what the refresh brings back, and nothing pushes that value to a panel already told the old one. So each automatic read showed the previous read's data, and because polling stops after six idle minutes, a person passively watching CI after a push never got a second read: the panel stayed on the old title or check state until they pressed Refresh. That matches the reporter's reproduction, where the automatic request receives the changed detail and the heading keeps the original title.

The cache comment in PullRequestService states the rule: reads that must not be answered from the hold go through invalidate rather than a flag on the read. The panel's poll is such a read, so it now takes that path. The cost is what the interval already intends to spend, one host read per open panel per tick, and the ten-second minimum interval still bounds the arrival reads.

Verified with web lint and typecheck. The change is wiring on top of the existing manual-refresh path, so it adds no test of its own.

Model and harness: Claude Fable 5.1 in Claude Code.

---

Note

Low Risk
Small client-side wiring change to refresh semantics for one panel; invalidation is scoped to a single PR reference and reuses the existing manual-refresh command.

Overview
Automatic pull request panel refresh (interval + return-to-window via useLiveRefresh) now invalidates that PR on the server before re-fetching detail, matching the manual Refresh path instead of calling detailQuery.refresh() alone.

Ordinary detail reads can be answered from the server’s held snapshot while a background refresh runs, which left passive viewers stuck on stale titles/checks until they hit Refresh. Polls are wired through a new refreshDetailFromHost callback (invalidate then detail refresh); the menu refresh still invalidates and refreshes detail, activity, and diff via the existing token path. Comments were updated to document poll vs manual behavior.

^{Reviewed by Cursor Bugbot for commit 9cf9cf6. Configure here.}

Note

Fix PullRequestDetailPanel polling to invalidate cached PR data before refresh

The live-refresh (polling) callback in PullRequestDetailPanel.tsx now invalidates the pull-request data for the current environment and reference before re-fetching the detail query. Previously, polling read the existing cached response directly, which kept it stuck on the server's held data. The manual refresh path was already doing this and is unchanged.

^{Macroscope summarized 9cf9cf6.}

[macroscopeapp]

Approvability

Verdict: Approved at 9cf9cf6

Macroscope's review found this PR approvable — This is a focused one-file bug fix that makes existing pull-request polling bypass the server’s held snapshot before refreshing detail data. It preserves the established polling cadence and scopes invalidation to the current pull request, with no schema, infrastructure, security, or static-analysis changes.

^{You can add or adjust custom eligibility rules. Learn more.}