feat: integrate InstanceType into Workload webhooks and controller manager, with E2E tests

[JoseSzycho]

Problem

With the InstanceType CRD established (Issue 1), the platform now needs to consume it:

1. Workload and WorkloadDeployment admission webhooks do not yet validate instance type names against the live catalog, nor do they warn developers about deprecated tiers or block disabled ones.
2. The compute controller manager (InstanceReconciler) still resolves CPU and memory from the static Go pkg/instancetype map when generating Milo ResourceClaim objects.
3. There are no automated end-to-end tests validating the entire pipeline—from Workload submission and catalog lookup to Milo quota reservation and lifecycle condition updates.

Proposed Scope of Work

Wire InstanceType into workload admission and controller-manager reconciliation, and validate the complete flow with automated E2E tests.

1. Workload & WorkloadDeployment Admission Webhooks

Update admission validation to query the InstanceType catalog:

• Unknown Type Validation: Reject workloads requesting an instance type that does not exist in the cluster.
• Default Resolution: When spec.runtime.resources.instanceType is omitted, default to the InstanceType designated with spec.default: true.
• Deprecated Tiers: Allow deployment of deprecated tiers, but issue an admission warning directing the user to spec.lifecycle.replacementInstanceType.
• Disabled Tiers: Block new workload deployments targeting disabled instance types with an explicit error:
  "InstanceType '<name>' is disabled; please update your workload to '<replacement>'."

2. Controller Manager Integration (compute-manager)

• Dynamic Quota Sizing: Update resolveInstanceResources in internal/controller/instance_controller.go to resolve CPU millicores and memory MiB directly from the cached InstanceType CRD instead of the static pkg/instancetype table.
• Accurate Milo Claims: Ensure the generated quotav1alpha1.ResourceClaim reserves the exact vCPU and memory quantities declared on the matching InstanceType.
• Deprecation Status Conditions: On every reconcile pass of WorkloadController, if a workload's referenced InstanceType has spec.lifecycle.phase: Deprecated or Disabled, set an observed warning condition on the workload (workload.status.conditions: Type: InstanceTypeDeprecated / InstanceTypeDisabled) detailing the recommended replacement.

3. End-to-End (E2E) Test Suite (Chainsaw)

Add a comprehensive Chainsaw test suite (e.g. test/e2e/instance-types/):

• Scenario A: Standard Deployment & Quota Verification
  • Create an InstanceType (d1-standard-2: 1 vCPU, 2048 MiB).
  • Submit a Workload referencing d1-standard-2.
  • Assert the generated ResourceClaim contains compute.datumapis.com/vcpus: 1000m and compute.datumapis.com/memory: 2048Mi.
  • Assert the instance runs successfully once quota is granted.
• Scenario B: Default Instance Type Fallback
  • Submit a Workload without specifying instanceType.
  • Assert it automatically binds to the default InstanceType and receives matching quota claims.
• Scenario C: Deprecation Lifecycle & Status Condition
  • Update d1-standard-2 to spec.lifecycle.phase: Deprecated with replacementInstanceType: d2-standard-2.
  • Verify that the running workload's status receives condition Type: InstanceTypeDeprecated.
  • Verify that existing instances continue to run without disruption.
• Scenario D: Disabled Rejection
  • Create a disabled InstanceType.
  • Attempt to deploy a new Workload targeting the disabled type.
  • Assert admission webhook rejects the deployment with the actionable replacement message.

---

Acceptance Criteria

• Workload admission webhook rejects unknown and disabled instance types, while issuing warnings for deprecated ones.
• compute-manager reads vCPU and memory from the live InstanceType cache for Milo ResourceClaim quota accounting.
• Deprecated or disabled instance types surface warning conditions in workload.status.conditions.
• Chainsaw E2E test suite passes in local testing and in GitHub Actions CI.