Keep frontend generated API client in sync with backend Swagger

### Checks

- [x] I have searched the [existing issues](https://github.com/kubeflow/notebooks/issues).
- [x] My request is related to one of the components in the [`kubeflow/notebooks`](https://github.com/kubeflow/notebooks) repository.

### Motivation

## Problem

While working on #1370, I noticed that the frontend generated API client is still pinned to an older backend Swagger revision through:

`workspaces/frontend/scripts/swagger.version`

When I regenerated the client against the current backend Swagger, it pulled in substantial API drift unrelated to the `filterRules` change, including newer Workspace API endpoints and generated contract changes.

This is similar to #1314, which was split out from #1310 because regeneration also pulled accumulated backend API drift.

## Current behavior

Both sides already have deterministic generation and CI verification:

- the backend generates and verifies `workspaces/backend/openapi/swagger.json`
- the frontend generates its API client from the exact backend commit pinned in `workspaces/frontend/scripts/swagger.version`
- the frontend CI verifies that generated files match that pinned revision

The missing piece is synchronization between them.

Backend Swagger can advance while `swagger.version` remains pinned to an older commit. The drift then accumulates until a frontend feature needs a newer API contract, at which point regeneration can pull unrelated API changes into that feature PR.

## Related

- #1370
- #1314
- #1310

### Implementation

## Proposal

Add a dedicated frontend API synchronization workflow.

### Proposed GitHub workflow

| Stage | What happens | Edge case / boundary |
| --- | --- | --- |
| 1. Detect | Trigger only when `workspaces/backend/openapi/swagger.json` changes on `notebooks-v2` | Normal backend commits that do not change the API do nothing |
| 2. Resolve revision | Use the latest verified `notebooks-v2` commit SHA as the frontend Swagger revision | No LLM or decision engine chooses the SHA |
| 3. Sync pin | Update `workspaces/frontend/scripts/swagger.version` to that revision | We keep the existing SHA-pinning design instead of changing how generation works |
| 4. Generate | Run the existing `npm run generate:api` process | Uses the existing generator; no Dependabot or additional code-generation system is introduced |
| 5. Guard scope | Verify that only `swagger.version` and generated frontend API artifacts changed | If unexpected handwritten files change, the workflow stops |
| 6. Find sync PR | Check whether an API-sync PR is already open | Use GitHub CLI (`gh pr list`) against `notebooks-v2` to find an existing same-repository sync PR; this avoids creating duplicates |
| 7. Create or update | If none exists, create a sync branch/PR; otherwise update the existing one | Use normal Git commands to update the branch and GitHub CLI (`gh pr create`) only when a new PR is needed |
| 8. Preserve human work | When updating an existing sync branch, keep commits already added by contributors | No force-push; if there is a real conflict, stop and let a human resolve it |
| 9. Verify | Existing frontend CI and E2E tests run normally on the sync PR | If generated API changes break handwritten frontend code, CI exposes it |
| 10. Human fix | A contributor adds compatibility changes if required | The automation does not try to understand or rewrite application logic |
| 11. Merge | A project member reviews and merges the PR | No automatic approval or automatic merge |

The workflow is intentionally deterministic. It does not use Dependabot or an LLM. GitHub Actions only performs the missing synchronization step using the repository's existing Swagger pin and API generator. Human judgment stays at the point where generated API changes affect handwritten frontend code.

This keeps the responsibility of the automation small:

```text
verified Swagger change
↓
advance pinned SHA
↓
run existing generator
↓
maintain one synchronization PR
````

The goal is to keep generated API drift out of unrelated frontend feature PRs while preserving the existing deterministic generation, CI, and project-member review process.

Happy to work on the implementation and testing.

### Are you willing & able to help?

* [x] I am able to submit a PR!
* [x] I can help test the feature!

Start with workspaces/backend/openapi/swagger.json, workspaces/frontend/scripts/swagger.version, the existing npm run generate:api process, and frontend CI/E2E checks. Trace how the current pin and generated artifacts are verified, then define the workflow around gh pr list and gh pr create. Done means verified Swagger changes maintain one synchronization PR, preserve existing commits, stop on conflicts or unexpected file changes, and pass normal CI.

Written by the indexing model from the issue text.