Before, on an IPv6-only cluster the script rewrote kind's
`https://[::1]:PORT` kubeconfig entry to `https://localhost:PORT`
unconditionally. That breaks any host whose `/etc/hosts` leaves
`localhost` off the `::1` line, including the Ubuntu cloud image Lima
runs. Remove the repoint logic, but note that limactl re-forwards the
published port to the host's v4 loopback only, so a macOS client cannot
directly access kind clusters run inside a Lima VM via `[::1]`. Instead,
operations should run inside the guest.

Tested: manual tests creating IPv6-only kind clusters on a local env
with IPv6 egress, namely macOS + Lima VM.

CoreDNS inherits the node's IPv4 resolver, which a v6-only pod cannot
reach. Change CoreDNS's Corefile to forward to an overridable IPv6
upstream. Also add a kind-registry:53 server block to CoreDNS. In
addition, `kind create` returns before the apiserver answers, so add
logic to wait for the control plane from inside the node first.

Tested: manual tests of creation and installation on a local env with
IPv6 egress, namely macOS + Lima VM. CI cannot verify this — the GitHub
runner is IPv4-only, so an IPv6-only cluster there additionally needs
DNS64 and NAT64.

GitHub-hosted runners only support IPv4. To allow IPv6-only kind
clusters to reach external services in this environment, we need
NAT64 translation.

This change introduces an `IPV6_DNS64_PREFIX` flag to opt into NAT64.
When set, it deploys the `kubernetes-sigs/nat64` agent and configures
CoreDNS and the node `podSubnet` accordingly.

Tested: via the IPv6-only kind e2e workflow on GitHub runners (which
have no IPv6 egress). Cluster creation and the full Agent Substrate
install succeeded, which includes downloading the gVisor runtime from
Google Cloud Storage.