Fix pagination issue with the pods list

What does this MR do and why?

Fix pagination issue with the pods list

Previously, the page is updated to the first page if any changes occur to the pods list. With the change, the page will remain if it exists. If the page is no longer available, it will navigate to previous.

Changelog: fixed

References

• Facing pagniation issue in envioment details (gitlab-org/cluster-integration/gitlab-agent#767) • Anna Vovchenko • 18.6

Screenshots or screen recordings

Before	After

How to set up and validate locally

Prerequisites:

• NGINX, loopback interface, and HTTPS set up on your GDK
• Docker instance
• KAS enabled on GDK (steps 1-2 from the guide).

1. Visit the Project -> Operate -> Kubernetes clusters page and create an agent following the instructions from the modal.

   • Select the "Connect a cluster" button
   • The modal should pop up
   • In the modal select "Name of the agent"
   • Create a new agent by typing the name of your choice
   • Select "Create and register"
   • Select the button and click "Register" in the next view.
   • Save the token to use it in the next point.

2. Add the following configuration inside your project in .gitlab/agents/<your-agent-name>/config.yaml for the user_access agent:

   user_access:
     access_as: 
       agent: {}
     projects:
     - id: <your-group>/<your-project-to-share-agent-with>

3. Note that the shared agents should be connected to the cluster in order to appear in the list. Please follow points 3-8 from the guide and then the Deploy the GitLab Agent (agentk) with k3d section to create a local cluster and connect your agent with the cluster.

4. Visit Project -> Operate -> Environments

5. Create/Edit an environment using the UI

6. Select an agent from the dropdown in the Environments settings page and save the change.

7. Visit the Environments page and visit the environment details page for the environment that has an associated agent.

Validation Scenarios

Scenario 1: Pod Status Updates (Main Fix)

Goal: Verify users stay on their current page when pod statuses change

1. Navigate to page 2+ in the pods table

2. Trigger status updates:

   • Wait for natural pod status changes, OR
   • Manually trigger pod restarts/updates in your cluster
   • Watch for real-time updates in the UI

3. Expected behavior:
   ✅ User should stay on the same page number
   ❌ User should NOT be kicked back to page 1

Scenario 2: Search Functionality

Goal: Verify pagination resets when user searches

1. Navigate to page 2+ in the pods table
2. Use the search box to search for specific pods (e.g., "nginx")
3. Expected behavior:
   ✅ Should reset to page 1 to show search results
   ✅ Search results should be displayed properly

Scenario 3: Status Filter

Goal: Verify pagination resets when user filters by status

1. Navigate to page 2+ in the pods table
2. Click on a status badge in the stats section (e.g., "Failed", "Running")
3. Expected behavior:
   ✅ Should reset to page 1 to show filtered results
   ✅ Only pods with selected status should be displayed

Scenario 4: Pod Deletion

Goal: Verify smart pagination when pods are deleted

1. Navigate to page 3 (ensure you have 25+ pods)
2. Delete several pods to reduce total to ~15 pods (2 pages)
3. Expected behavior:
   ✅ Should navigate to page 2 (last available page)
   ❌ Should NOT jump to page 1

Scenario 5: Extreme Reduction

Goal: Verify fallback to page 1 when necessary

1. Navigate to page 3+
2. Delete most pods leaving only 5-10 pods (1 page total)
3. Expected behavior:
   ✅ Should navigate to page 1 (only available page)

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to gitlab-org/cluster-integration/gitlab-agent#767