#7577 Pull Requests: selecting a PR locks the list to that repo

Summary

Opening a PR from the Pull Requests list silently applies a project/repo filter to the list, so the list collapses to just that repo.
While the PR detail is open, that filter cannot be removed — clearing or changing it immediately re-applies the selected PR's project.
Effect: you can't browse or compare PRs across repos while reading one. To get the full list back you have to close the detail pane.

Steps to reproduce

Open the Pull Requests view with no project filter set, showing PRs from several repos.
Click a PR from the list to open its detail view.
Observe the list is now filtered to that PR's repo.
Try to clear the project filter (or select a different project) while the detail is still open.

Expected

Selecting a PR shouldn't change the list's filters. The project filter should stay independently controllable while a PR is open.

Actual

The filter is set to the selected PR's project and re-asserts itself on every attempt to change it.

Cause

Two places in the Pull Requests layout (layout-CSU-GANo.js in the 1.26.0 renderer build) push the selected PR's project into the route search, which is what projectFilters is derived from:

handleOpenPreview navigates with the clicked PR's project baked in:

navigate({
  to: "/pull-requests/$prNumber",
  params: { prNumber: String(pr.prNumber) },
  search: { search: ..., project: pr.projectId, projects: serializeProjectFilters(projectFilters), ... }
})

navigateTo — used by every filter change handler — force-injects the selected PR's project after the caller's search object, so it overrides whatever the user just chose:

const navigateTo = useCallback((search) =>
  selectedPrNumber != null
    ? navigate({
        to: "/pull-requests/$prNumber",
        params: { prNumber: String(selectedPrNumber) },
        search: selectedPrProjectId ? { ...search, project: selectedPrProjectId } : search,
        replace: true,
      })
    : navigate({ to: "/pull-requests", search, replace: true }),
[navigate, selectedPrNumber, selectedPrProjectId]);

Because project: selectedPrProjectId is spread last, an explicit "clear projects" can never win while a PR is selected. The filter store's own comment ("views sync filters back through an effect, so an always-fresh array here becomes an infinite update loop") suggests this coupling has already caused trouble.

Suggested fix

Keep the selected PR's project as a detail-pane concern rather than a list filter — e.g. carry it in the route params or a separate search key that the list's projectFilters doesn't read from, and stop re-injecting it in navigateTo. At minimum, don't let the injected project override an explicit user filter change (spread it first, or omit it when the user has just set filters).

Possibly in scope of the #5596 GitHub & PR integration tracker (cf. stale #4329 "PR list remember project", which is about remembering rather than locking).
Companion issue on GitHub API volume in this same view: filed separately.

Environment

Superset 1.26.0, macOS Darwin arm64

Pull Requests: selecting a PR locks the list to that repo