Allow instance groups to change zones when repairing VMs (#2914)

## Summary

Every Linux and Windows agent VM runs a single job and then powers off
(`disconnect-after-job=true` + `ExecStopPost=/bin/systemctl poweroff`).
The instance group then repairs the VM by recreating it, and by default
a repair must recreate the VM **in the same zone**. When that zone runs
out of capacity, recreated VMs get stuck retrying there
(`ZONE_RESOURCE_POOL_EXHAUSTED`), even if other zones in the region have
room. That's what happened to `bk-docker-arm64` and
`bk-testing-docker-arm64` on 2026-10-01: all stuck VMs sat in
us-central1-c.

This change sets
[`--on-repair-allow-changing-zone=yes`](https://cloud.google.com/compute/docs/instance-groups/autohealing-instances-in-migs)
for all regional instance groups so a repair can recreate the VM in
another zone. GCE requires `--force-update-on-repair` for that, which
also makes repaired VMs pick up the group's latest configuration.

## Changes

- `create_instances.py`: new `on_repair_allow_changing_zone` option.
When it's set on a regional group, the MIG is created with
`--force-update-on-repair --on-repair-allow-changing-zone yes`.
- `instances.yml`: enable it in `default_vm`, so it applies to all
instance groups.

## Notes

- This doesn't reserve capacity, it only avoids getting stuck in one
zone. Reservations would be needed to hold capacity across recreates.
- Already enabled manually on `bk-testing-docker-arm64` and
`bk-docker-arm64`. Other groups get it the next time
`create_instances.py` recreates them.

## Testing

Ran `create_instance_group()` against the real `instances.yml` with
`gcloud` stubbed out. All 9 groups get both flags on the MIG create
command, and instance templates are unchanged. `black --check` passes.