This PR provides a single n2 slice (n2-standard-32-2) XPK example setup to:

1. Enable existing Cluster Toolkit users to quickly try a "getting started"-type XPK setup
2. Highlight the server-side components of XPK (which otherwise requires significant XPK reverse engineering, given the imperative and Python-based core of XPK)
3. Provide reference code for introducing XPK components into other blueprints/setups

Design decisions:

• Heavy version pinning, given the developing v0 nature of XPK, Kjob, and Kueue
• Use of f775609365df47bdc3e7c10290d8efae7f512464 for Kjob, based on the need for >v0.1.0 given XPK's use of --pod-template-annotation, but no >v0.1.0 release (the two tags v0.2.0-devel and v0.1.0 are on the same commit). This will be switched to a proper tagged release, upon the next XPK release. f775609365df47bdc3e7c10290d8efae7f512464 is specifically chosen, as it is just prior to the dependabot version bump of Kueue to v0.11.2 (Cluster Toolkit currently covers up to v0.11.1). The kjob CRD manifest links are deliberately structured to accept either a version tag or a commit hash.

Manually tested various happy-path and non-happy-path scenarios. Testing confirmed functionality of all relevant xpk commands: workload, storage, cluster, inspector, info, batch, job, shell, version, config, and run.

Submission Checklist

• ✅ Fork your PR branch from the Toolkit "develop" branch (not main)
• ✅ Test all changes with pre-commit in a local branch #
• ✅ Confirm that "make tests" passes all tests
• ✅ Add or modify unit tests to cover code changes
• ✅ Ensure that unit test coverage remains above 80%
• ✅ Update all applicable documentation
• ✅ Follow Cluster Toolkit Contribution guidelines #