UID2-7823: add the azure-cli apt repo before installing

[mcollins-ttd]

What

pin_azure_cli now adds Microsoft's azure-cli apt repository before installing, and pins the exact deb revision (azure-cli=2.87.0-1~noble) rather than matching on a 2.87.0* glob.

Why

The AKS E2E job fails at the Pin Azure CLI step with E: Version '2.87.0*' for 'azure-cli' was not found. That skips cluster setup and the tests, and also leaves the always() cleanup step ("Stop AKS operator") failing, since az account set then runs with no prior az login.

The runner image installs azure-cli and then deletes Microsoft's azure-cli apt source. Until recently that delete missed the file — Microsoft's installer writes azure-cli.sources (deb822) while the cleanup removed only azure-cli.list — so the repo stayed configured and pinning a version worked by accident. actions/runner-images#14652 broadened the cleanup to azure-cli.*, so no configured repo carries azure-cli at all.

Evidence: the last successful run (2026-08-18) fetched azure-cli 2.87.0-1~noble from packages.microsoft.com/repos/azure-cli and downgraded from 2.89.0. The failing run has only ubuntu/24.04/prod configured, which does not carry the package.

Notes

• The pin is still required. 2.87.0 bundles Python 3.13, while 2.89.1 (preinstalled on the runner) and 2.90.0 bundle Python 3.14, which hits the msal deadlock in Support Python 3.14 Azure/azure-cli#32869 — still open.
• The added steps are Microsoft's documented install procedure, and match the workaround the runner-images maintainer recommends in az-cli cannot pin a version actions/runner-images#12361. GitHub does not support pinning the az version, so re-adding the repo is the sanctioned approach.
• install_az_cli in uid2-operator already configures this repo, which is why its jobs kept passing while this one broke. Folding the two together is a follow-up.
• This reaches consumers when the v3 tag next moves; no caller changes are needed.

Ticket: UID2-7823