agent config e2e: advertise Kind control-plane VM-bridge node IP

[plombardi89]

Summary

Fixes the agent config e2e flake in #467 where worker nodes stay NetworkPluginNotReady and the job times out after 720s.

Kindnet on the QEMU worker nodes installs the control-plane pod CIDR route via the control-plane Node's InternalIP. By default that is the Kind container's Docker-network address (for example 172.18.0.2), which is not on-link from the VM bridge subnet the workers live on. The ip route add then fails:

Adding route ... Dst: 10.244.0.0/24 Gw: 172.18.0.2
Failed to reconcile routes, retrying after error: network is unreachable
panic: Maximum retries reconciling node routes: network is unreachable

Containerd never gets a CNI config and the worker never becomes Ready.

Change

Add a configure-kind-node-ip step that reconfigures the Kind control-plane kubelet to advertise its VM-bridge address (${VM_SUBNET}.2, already assigned to eth-e2e) as the Node InternalIP, before any worker joins. That makes the pod-CIDR next hop on-link for every worker, so route reconciliation succeeds.

• hack/agent/e2e-kind/e2e.py: new idempotent configure-kind-node-ip command (rewrites KUBELET_KUBEADM_ARGS, restarts kubelet, waits for the Node to advertise the new IP).
• .github/actions/agent-e2e-kind-control-plane/action.yaml: run it immediately after the Kind container is attached to the VM bridge.
• hack/agent/e2e-kind/run-local.sh: same call for local runs.

CONTROL_PLANE_ENDPOINT is intentionally left on the Docker IP (covered by the API cert SANs); only the Node's advertised InternalIP (a routing next hop, not a TLS endpoint) changes.

Verification

• Static: python3 -m py_compile, AST/command-registration checks, bash -n, PyYAML parse, CI step-ordering assertion.
• Isolated repro (network namespace): ip route add 10.244.0.0/24 via <docker-ip> fails; via <bridge-ip> succeeds.
• Real Kind cluster end-to-end: ran the actual configure-kind-node-ip command; the control-plane Node advertised 192.168.110.2 within 3s; a worker netns on the VM subnet reached that IP (ping) and installed the pod-CIDR route via it, while the old Docker-IP route still failed.

Notes

The existing crash-looping-Kindnet-pod deletion workaround in e2e.py is left in place as a safety net; this change removes the cause.