The problem was down to the VM to which the volume was attached existing in a “Shelved/Offloaded” state. This means that it isn’t running or allocated to a hypervisor, but its volumes and network information still exist in our database.
Because attaching or detaching a volume requires communication with the VM, and the VM wasn’t allocated to a hypervisor, this volume failed to detach because the VM couldn’t be contacted to confirm that the volume really wasn’t present any longer.
This VM was shelved/offloaded by us in our security audit before Christmas - you would have been contacted about this. We chose to shelve VMs that failed the audit rather than terminate them completely specifically to help in situations like this - they are no longer susceptible to password attacks because they are shelved, but we can still get to your data in an emergency.
TL; DR - this wasn’t your fault, or caused by anything you did. You took the correct approach and asked us to look at it, we were able to do some things on the backend to get the volume to detatch.