test(e2e): run tenant workers on one vCPU with CPU headroom above it (#3863)

## What this PR does

Moves the e2e tenant workers from two vCPUs to one, keeping a CPU limit
above the vCPU count: `resources.cpu: 1` with `podCpuLimit: 2` and
`podCpuRequest: 100m`.

This is the next step of the cozystack/cozystack#3513 measurement
series. With two vCPUs the failing worker's two vCPU threads burn 1.4 to
1.8 cores between them while the guest kernel never gets past SMP
bringup, and raising the CFS ceiling from 2 to 3 cores (#3862) changed
neither the burn nor the progress, so the spin is between the two vCPUs
rather than against the quota. A single-vCPU guest has no sibling vCPU
to spin on, which is exactly what this shape tests. The ceiling of 2
keeps the QEMU emulator and IO threads from eating into the one core the
guest computes with, which was the failure shape of the original
single-vCPU workers whose quota equalled their vCPU count. The request
of 100m is what KubeVirt derived for a one-vCPU worker before, so
scheduling does not move.

Like its predecessors this changes only what the e2e suites run, not
what any chart ships by default.

### Screenshots

Not applicable, no UI change.

### Downstream repositories

The diff is one values block inside
`hack/e2e-chainsaw/_lib/run-kubernetes.sh`. 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
test(e2e): tenant workers in the kubernetes e2e suites run on one vCPU with a CPU limit of two, testing whether the node-join freeze is a spin between sibling vCPUs
```

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

@@ -3167,24 +3167,24 @@ ${ouroboros_addon}
       # ceiling. Workers failing to join (cozystack/cozystack#3513) have been
       # measured burning their vCPU threads flat out at a ceiling equal to their
       # vCPU count while the guest kernel made no progress, which is what a vCPU
-      # spinning on a lock looks like when the vCPU holding that lock is the one
-      # preempted out of the quota they share. Whether the spare CPU lets the
-      # preempted one back in is what this is here to answer. The request is
+      # spinning on a lock looks like. Spare quota above the pair did not change
+      # it: under a ceiling of 3 the pair kept burning the same 1.4 to 1.8 cores
+      # with no progress, so the spin is not a quota artefact. A single vCPU
+      # cannot spin on its sibling, which is what this shape is here to answer,
+      # and the ceiling above the vCPU count keeps the emulator and IO threads
+      # from eating into the one core the guest computes with. The request is
       # what keeps scheduling where it was: setDefaultResourceRequests, in
       # KubeVirt's VMI mutating webhook, copies a declared CPU limit into an
       # undeclared CPU request, so the limit alone would have every worker ask
       # the scheduler for its whole ceiling and sit Pending on Insufficient cpu.
       # Its value is the one KubeVirt derived for these workers before, from the
       # vCPU count and the cluster CPU allocation ratio.
-      podCpuLimit: 3
-      podCpuRequest: 200m
-      # 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.
+      podCpuLimit: 2
+      podCpuRequest: 100m
+      # One vCPU at the memory the workers had before. Sized by resources
+      # rather than by instanceType, which cannot carry the pod CPU pair above.
       resources:
-        cpu: 2
+        cpu: 1
         memory: 4Gi
       roles:
       - ingress-nginx