Glad you got it back up and running.
I'm not certain, but a missing /usr/local/bin/xo-server right after an XOA update usually looks like an update that got interrupted or only half-applied, so the service ends up pointing at a binary that never got laid down.
I think the gentler recovery before rebuilding would have been re-running the updater from the CLI; there's a writeup here: https://docs.xen-orchestra.com/xo5/updater#from-the-cli, which often repairs a broken update in place.
The vm-destroy refusal is expected by the way: XOA sets blocked_operations as a safety net so you can't accidentally destroy your own orchestrator, so that flag has to be cleared first. I could easily be wrong on the exact trigger, though, and if it ever happens again on a fresh update, @Team-XO-Backend would be the ones who could tell whether a specific update is implicated.
