fix(e2e): size tenant workers by resources, not by u1.large (#3840)

## What this PR does

Follow-up to #3839, which moved the e2e tenant workers to `u1.large` to
give them a second vCPU. That instancetype doubles memory along with the
vCPUs, and four 8Gi workers do not fit on the sandbox beside the rest of
the suite. On the first runs after it landed, the second worker of each
cluster stayed Pending with `0/3 nodes are available: 3 Insufficient
memory`, so the node group never reached two Ready nodes and node-join
failed for a reason unrelated to the CPU ceiling the change was meant to
test. The memory estimate in that PR body counted the workers against
total node memory and did not account for what the rest of the suite
already occupies.

This sizes the group with `resources.cpu` and `resources.memory`
instead, which keeps the two vCPUs at the 4Gi the workers had before.
The chart omits the instancetype from the VM whenever a group sets both
fields, since KubeVirt rejects a VM that references an instancetype and
also overrides CPU or memory, and the values schema still lists
`instanceType` as required, so it stays in the values as the fallback it
now is.

The measurement from those runs is worth keeping even though the runs
were spoiled. Where the workers did start, the two-scrape capture read
1.46 to 1.93 against the new ceiling of 2.0, with 2 to 5 percent of CFS
periods throttled, against 0.93 to 0.98 of a 1.0 ceiling at 8 to 13
percent throttled before. The ceiling was binding, and raising it does
loosen it; whether that is enough to make the join deadline is what the
next runs measure.

### Screenshots

Not applicable, no UI change.

### Downstream repositories

The diff is one values block inside
`hack/e2e-chainsaw/_lib/run-kubernetes.sh`. Nothing under `hack/` is
moved or renamed, no make target changes behaviour, no package, schema,
default or CRD changes. Nothing in the trigger map is touched.

- [x] No downstream repository is affected by this change
- [ ] [cozystack/website](https://github.com/cozystack/website) -
follow-up:
- [ ]
[cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack)
- follow-up:
- [ ]
[cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack)
- follow-up:
- [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up:
- [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up:
- [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) -
follow-up:
- [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) -
follow-up:
- [ ]
[cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server)
- follow-up:
- [ ]
[cozystack/external-apps-example](https://github.com/cozystack/external-apps-example)
- follow-up:
- [ ] [cozystack/examples](https://github.com/cozystack/examples) -
follow-up:

### Release note

```release-note
fix(e2e): tenant workers in the kubernetes e2e suites keep their two vCPUs but go back to 4Gi of memory, since the larger instancetype left workers unschedulable on the sandbox
```


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Configuration**
  * Updated tenant worker nodes to use `u1.medium` instances.
  * Set each worker’s resources to 2 CPUs and 4 GiB of memory.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

hack/e2e-chainsaw/_lib/run-kubernetes.sh

@@ -2651,7 +2651,10 @@ ${ouroboros_addon}
     md0:
       diskSize: 20Gi
       gpus: []
-      instanceType: u1.large
+      # Sizing comes from resources below; this is here because the values
+      # schema requires the field, and the chart drops the instancetype from
+      # the VM whenever a group sets both resources.cpu and resources.memory.
+      instanceType: u1.medium
       # The failure this suite keeps hitting is a worker that stalls in the
       # guest before Talos apid answers, which leaves nothing to read on the
       # management side and nothing for talosctl to connect to. Turning this on
@@ -2660,7 +2663,14 @@ ${ouroboros_addon}
       logSerialConsole: true
       maxReplicas: 10
       minReplicas: 2
-      resources: {}
+      # Two vCPUs at the memory the workers had before. Sized by resources
+      # rather than by instanceType: u1.large doubles memory along with the
+      # vCPUs, and four 8Gi workers do not fit beside the rest of the suite,
+      # so the second worker of each cluster stayed Pending on Insufficient
+      # memory and the node group never reached two Ready nodes.
+      resources:
+        cpu: 2
+        memory: 4Gi
       roles:
       - ingress-nginx
   storageClass: replicated