[TASK] Implement policy for handling swagger.version on release

[andyatmiami]

Certification

• I certify I am an Epic Owner for Kubeflow Notebooks 2.0 and expected to create planning-related issues.

Description

As part of the work to implement auto-generated HTTP client code in the frontend, we use a file named swagger.version to determine which specific commit of the backend swagger.json should be used to drive code generation.

This convenience to allow frontend to control when to pull in new changes works great for development - but its less clear if this flexibility is desirable for releases.

---

@caponetto proposed (and I personally agree) that we should enforce a check on release builds such that the swagger.version file must contain the commit hash that equals or contains the latest commit hash of swagger.json when changes were introduced.

• i.e. we should only build a release if we are sure the frontend has been configured to operate on the most recent swagger.json changes

ℹ️ In the future, when we have a robust and comprehensive set of tests - its possible this "update" could be handled programmatically in our GHA workflows - but given the lack of sufficient coverage in our testing framework today - the thought would be that we should just have a new GHA workflow (or add a step in the frontend workflow involved in publishing releases) that would fail if our agreed upon constraints aren't satisfied.

Acceptance Criteria

• Community consensus is reached on how swagger.version should be handled during releases
• Any appropriate checks (if required) are implemented in our CI to ensure we are compliant with our agreed upon approach