Summary

This PR fixes integration test failures caused by missing test data required for nodepool version validation. The core issue was that nodepool creation tests lacked serviceProviderCluster fixtures containing cluster version information, causing validation to attempt dereferencing nil pointers and crashing the test server.

Context: Why These Changes Are Needed

When nodepool version validation was introduced (to prevent version skew between nodepools and control plane), the validation logic began requiring serviceProviderCluster data to check active cluster versions. Many existing integration tests predated this requirement and never had this fixture data, causing them to fail with cryptic EOF errors when the validation code panicked.

Problem Investigation Summary

The EOF errors were masking the real issue - the test HTTP server was panicking and closing connections. The panic occurred at validators.go:960 when dereferencing a nil *semver.Version pointer. This pointer was nil because:

1. Tests lacked serviceProviderCluster fixtures entirely, OR
2. Tests had the fixture but loaded it AFTER attempting nodepool creation (due to alphabetical step ordering)

Changes Explained

1. Added Missing Test Fixtures

What to review: New 03-loadCosmos-serviceProviderCluster/serviceProviderCluster.json files across multiple test scenarios.

Why this approach: Each test scenario needs cluster version data that matches its test cluster. The fixture structure mirrors what the backend creates when clusters are created via HTTP API - it contains:

• active_versions array with semantic version strings (e.g., "4.20.0")
• desired_version in the spec

2. Fixed Test Step Execution Order

What to review: Directory renames from 03-httpCreate-* to 04-httpCreate-* (or 05- in some cases).

Why this matters: The test framework processes steps in lexicographical order. When both 03-httpCreate-nodepool and 03-loadCosmos-serviceProviderCluster existed, the former executed first because 'h' < 'l' in ASCII. This meant nodepool validation ran before the required cluster version data was loaded.

Solution rationale: Rather than changing the test framework's ordering logic (which would be risky), I renumbered directories to enforce correct execution order: load serviceProviderCluster at step 03, then create nodepool at step 04+.

Tests with multiple nodepools: Some tests (like create-current) have multiple 04-httpCreate-* steps. This is intentional and safe - as long as they all run AFTER the 03-loadCosmos step, the alphabetical ordering within step 04 doesn't matter.

3. Programmatic Fixture Creation in version_compliance_test.go

What to review: New createServiceProviderClusterForVersionCompliance helper function.

Why this pattern: The version_compliance_test.go creates clusters programmatically rather than from fixtures. To maintain consistency with its testing approach, it also creates serviceProviderCluster documents programmatically rather than loading from fixture files.

Alternative considered: I could have made this test load from fixture files like FrontendCRUD tests do, but that would break the test's design pattern of being fully self-contained and not relying on external JSON files.

Testing & Verification

Manual verification performed:

1. Ran full make test-integration - all tests pass
2. Specifically verified previously failing tests now pass: missing-required-fields, invalid-version, create-current, delete-not-last (these were failing for the modified code for skew validation PR feat: add node pool vs control plane version skew validations during nodepool creation #4566 )

Rollout Considerations

No production impact: These are test-only changes. No business logic modified, no API behavior changed.

Review Focus Areas

1. Step numbering consistency: Confirm all nodepool creation steps now occur after serviceProviderCluster load
2. No behavioral changes: Confirm no changes to validation logic itself - only test infrastructure