Fix the Destroy workflow: avoid the Azure CLI crash

[jaredthivener]

The Destroy workflow failed on its first real run (run), in the step I added in #173 and had not been able to test. Nothing was deleted: the next step, which deletes the resource group, was skipped.

Cause

az monitor log-analytics workspace delete --force crashed inside the Azure CLI before it sent anything:

ERROR: deadlock detected by _ModuleLock('requests.structures')

This is Azure/azure-cli#33996, open, with a fix proposed but not merged. On GitHub's Ubuntu runners the CLI bundles Python 3.14. Its long-running commands create their credential on a worker thread, and that thread's import of requests intermittently collides with the main thread's. Others report it for az network vnet create, az network nsg rule create and az lab create; rerunning sometimes passes.

Change

• The step sends the same permanent delete as the REST call Microsoft documents (DELETE …?force=true), through az rest. az rest does its work on one thread, so the collision cannot happen there.
• It then waits until the workspace is gone before the group is deleted.
• infra/README.md: the manual teardown uses the same call. The Azure CLI on a Mac from Homebrew also runs on Python 3.14.

Checked

Ran the step's script, as written in the workflow, against a scratch workspace in a scratch resource group: the workspace was gone 13 seconds later and was not in the recycle bin, so the delete is permanent.

Not checked

• That it avoids the crash on a runner. The bug is intermittent, so no single run proves it; the argument is that az rest has no second thread.
• The other commands in the workflows. az group delete --no-wait and the Deploy workflow's az aks start go through a different part of the CLI, which makes its first request on the main thread. Neither has failed so far.

🤖 Generated with Claude Code