I think you have some misconception about Scrum
So each knows their end of the woods but no one has the broader
In this case you don't have a team, you have a collection of people working on the same software. In Scrum the team work implements sprint goals to achieve a product goal each a broader perspective than a task
The QAs observe metrics on automated tests, A/B tests, support calls,
task completion statistics - but they too are engineers, not business
Support calls, at least nature and volume, and task completion statistic should also be checked by the PO, which is a business role.
The PO knows about the business goals but they do not understand the
technical aspects of "BUG X".
Do they truly understand the business if they don't understand how BUG X affect the business? The technical aspect is a business aspect, at least in difficulty and effort to solve. The technical details however should be entrusted to developer and the PO have trust in them (and developers need to earn and keep this trust)
So how should a roll-out happen in a sane organization? Who approves
it; based on input from whom? Do they use their private keys to deploy
or do they write an e-mail to engineering "OK, do it"?
It depends of the organization and functional context. "Sane" in finance and trading is not the same as e-commerce.
Ideally it would be no-one. It just rolls out when it's ready because you have automated everything possible and you just eventually have people with different role/credential to validate some steps.
Sometimes you can roll out when a developer click on "push" for it's code. Sometimes there are marketing campaign and you want to hold until a release date.
Bonus question: how should a roll-back happen?
It depends. Either easily or painfully. E-commerce you can roll back a commit and push to prod. A bug in automobile software you have to recall all vehicle or at least have them sent to a workshop for software update.