[ACE-1975] Use az aks command invoke to deploy through Azure ARM API, which bypasses the private AKS API endpoint

[osh0501]

Description

• Replaced kubelogin with az aks command invoke — Self-hosted runners behind corporate TLS proxy cannot validate AKS API certificates directly. az aks command invoke uses the Azure ARM API (authenticated via OIDC) to create temporary pods inside the cluster that run helm commands, avoiding proxy interference entirely

• Merged parallel jobs into a single sequential job — Previously deploy-orchestrator and deploy-catalog ran as independent parallel jobs. Combined into one deploy-services job with conditional steps to prevent namespace CPU quota conflicts (2 CPU limit). Retained conditional deployment flexibility — Can still deploy orchestrator only, catalog only, or both via deploy_orchestrator/deploy_catalog input flags.

• Uploaded only helm/ directory to temporary pod — Using cd helm && --file . uploads only the chart directory, avoiding "Request Entity Too Large" errors from uploading the entire repo checkout

• Removed kubelogin, aks-set-context, and use-kubelogin actions — No longer needed since az aks command invoke handles cluster authentication through ARM API

• Fixed --wait/--atomic redundancy — --atomic already implies --wait; refactored to elif to avoid specifying both flags simultaneously

• Infrastructure dependency (separate repo: DI-azure-infra-k8s): Requires adding Calico network policy for aks-command namespace (stg + prd) to allow the temporary pod to reach the K8s API server through the zero-trust networking tier.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist

• I have performed a self-review of my own code