[Feature] Improve handling of target k8s version being unavailable in cluster region

When using Azure Kubernetes Fleet Manager’s auto-upgrade with an approval gate (e.g., *stable* channel), an update run can enter `Pending` because the **target Kubernetes version isn’t yet available in the member cluster’s Azure region**. In this state, even if we approve the run, it returns to `Pending` until the regional rollout catches up—creating long, unpredictable waits after approval. From a user perspective, this feels like we “approved” something that couldn’t possibly proceed at that time.

Example: Target version `1.32.9` is detected and the run awaits approval. After approving, the run returns to `Pending` because in **Japan East** only up to `1.32.7` is available. Version availability differs by region and must be checked via the AKS Release Tracker and/or `az aks get-versions`, but the approval UX doesn’t account for that readiness.

If regional rollout is the gating factor, **approval should be possible only when the target version is actually available in the member cluster’s region** (or at least the system should clearly defer/queue the approval until it is). Concretely:

* When we click **Approve**, Fleet should **validate region readiness** for each member (or stage) against AKS’s regional availability. If not ready, the UI/CLI should:

* Block approval with a clear message, **or**
* Offer an “Approve when ready” mode that **auto-retries the approval once the target version becomes available** in that region (no manual re-approval required).
* The approval dialog should surface the **current regional status** (e.g., link to AKS Release Status and the versions available via `az aks get-versions`) so operators can make an informed decision without context-switching.

* **Wait and re-approve later**: Operationally brittle; operators may forget, and long pending periods after approval cause confusion.
* **Manually retarget to the latest version available in-region** (e.g., use `1.32.7` now and upgrade again to `1.32.9` later): Adds extra change windows and rollback risk.
* **Stage by region / skip not-ready clusters**: Reduces blocking but increases complexity; still doesn’t address the misleading “approved but not executable yet” state.

**Why this helps**

* Prevents approvals that cannot progress, reducing confusion and follow-up toil.
* Aligns approval intent with real execution readiness, especially in **safe, gradual regional rollouts** that naturally introduce timing skew between regions.