After many long conversations with the Azure tech people and lots of beating my head against the wall this was the eventual solution.
First, things were so corrupt at this point that no image file could be attached and no wrangling could fix the VM remotely.
We ended up detaching the drive from the current VM and deleting that VM instance (while retaining the old drive).
The next step was to create a new VM that was functioning and had all the necessary components. This was a bit of a complicated config, so this process has not been fun doing over again.
Once the new VM was completely set up and ready to go I attached the old drive to the currently working VM as a F: drive and migrated the data over by hand. Basically copying and pasting what was needed.
I am still working on safely migrating the MySQL database, but the majority of everything else is over on the new VM.
This was a major PITA and not a particularly satisfying way to restore a machine. I am also very worried that I missed something. I guess time will tell.
Please take this as a morality play on the dangers of using sysprep without clearly understanding what it does. They seriously need to put a label on that thing. It is damn dangerous.
Note - there was an alternative to this approach. I could have downloaded the VHD file for the machine and attempted to fix the instance using Hyper-V on my local system. At that point I could have uploaded it and started a new VM from that VHD. I chose not to do this because of the long upload/download time for the 130GB VHD file and the risk that it was going to be a futile effort.