ClusterTrustBundle v1 support - #1924

…a APIs (agent-substrate#1852)

Fixes agent-substrate#1819

When bootstrap finds an existing cluster without the PodCertificate beta
APIs, its reconcile path turns them on in place. That works: the APIs
are served once the update finishes. On 1.36 node pools it is only half
the repair, and nothing said so. Pod certificate projection is a kubelet
feature, gated through 1.36, so pods scheduled onto nodes that were
already running fail with `MountVolume.SetUp failed: unimplemented`
while the control plane looks healthy.

**What changes**

- After a successful beta-API update, setup-gcp warns once per node pool
below 1.37 and logs the two commands that fix it:
- `gcloud container node-pools create <pool>-2 …`, with the machine
type, disk, node count and nested virtualization copied from the old
pool;
- `gcloud container node-pools delete <pool> …` for once workloads have
moved.

The warning also says to carry over anything else customized on the old
pool (taints, service account, autoscaling). The pool's version decides
this, not the control plane's, since a 1.37 control plane can still run
1.36 nodes.
- The README warning is rewritten to match, building on the `v1`
discovery wording from agent-substrate#1924. It drops the claim that enabling the APIs
on an existing cluster doesn't make them served, which didn't hold up in
testing.
- `hack/ate-dev-env.sh.example` had the same claim in a comment; fixed
there too.

**Why a new pool, not an in-place node recreation**

The issue proposed recreating nodes, and the obvious command is
upgrading a pool to the version it already runs. GKE skips that: in
testing, the `UPGRADE_NODES` operation finished in 4 seconds and no node
was replaced. A pool can only be upgraded forward when GKE happens to
offer a newer patch. A new pool is the one GKE operation certain to
produce new kubelets.

Replacing the pool is left to the user rather than done automatically,
because it moves running workloads. A flag to do it could be a follow-up
if that would be useful.

**Verified end to end** on a throwaway 1.36.4 cluster created without
the beta APIs:

1. This branch's `create cluster` reconcile path enabled the APIs and
logged the warning for `default-pool`.
2. A pod with a pod certificate volume on the existing node failed with
`MountVolume.SetUp failed … unimplemented`.
3. The logged `node-pools create` command, pasted as printed, created a
pool whose kubelet issued a PodCertificateRequest for the same pod (the
mount then waited on `credential bundle is not issued yet`, as expected
with no signer running).
4. The logged `node-pools delete` command removed the old pool.

- [x] Tests pass (`go test ./tools/setup-gcp/...`)
- [x] Appropriate changes to documentation are included in the PR