feat: in-place resize of workspace resources on running sandboxes

[noeljackson]

Summary

When SandboxClaim.spec.workspaceResources is updated on a claim with an existing running sandbox, the controller now patches the pod's container resources in-place instead of silently ignoring the change.

On Kubernetes 1.27+ with InPlacePodVerticalScaling, this triggers the kubelet to call UpdateContainerResources on the container runtime, resizing the workload without restart.

Previously, resource changes on existing claims logged "sandbox already exists, skipping update" and returned without action.

Changes

• Added reconcileWorkspaceResources() to the SandboxClaim controller reconcile loop. When a sandbox already exists, this compares the claim's workspaceResources with the pod's current container resources and patches them if they differ.
• Added buildResizePatch() helper that builds the resource diff. Only CPU and memory are compared. DiskGB (ephemeral storage) is intentionally excluded because it cannot be resized in-place.
• The pod patch uses a strategic merge patch on the pod spec, which the API server routes through the resize admission path on K8s 1.27+.

How it works

kubectl patch sandboxclaim my-claim \
  -p '{"spec":{"workspaceResources":{"memoryMB":512,"cpuMillicores":2000}}}'

1. SandboxClaim controller reconciles, finds existing sandbox
2. Looks up the owned pod, finds the "workspace" container
3. Compares current resources with desired workspaceResources
4. If different: patches pod resources via strategic merge
5. Kubelet detects the change and calls UpdateContainerResources on the runtime

Test plan

• Existing unit tests pass (go test ./extensions/...)
• Create SandboxClaim with workspaceResources: {memoryMB: 256, cpuMillicores: 1000}
• Wait for pod running
• Patch claim with memoryMB: 512, cpuMillicores: 2000
• Verify pod resources updated without pod restart
• Verify no-op when patching with same values (no unnecessary updates)