I also work in an environment where interruptions are something unavoidable. Basically, critical live production problems will take priority over regular development. We try to shield the team by having other people do this work but sometimes their involvement is necessary. So yes, practice is very different than theory. But by talking about theory we try to work towards an ideal situation, and make transparent the things that are keeping us from that ideal.
The team should not be (overly) discouraged at a sprint cancellation from external sources. The narrative is "folks, we need to cancel the sprint because so and so has asked/directed that we drop everything because this new thing is really important and they need our help".
As you say, if business can give warning it would help greatly. And X weeks = 2 since your sprints are 2 weeks. My recommendation would be to try to integrate these interruptions into the scrum process. I.e. have stories or PBIs prepared for them and do them as a standard sprint.
Looking at the scrum guide...
For the Product Owner to succeed, the entire organization must respect his or her decisions. The
Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No
one is allowed to tell the Development Team to work from a different set of requirements, and
the Development Team isn’t allowed to act on what anyone else says
In your context, this means that these interruptions should flow through the Product Owner. If business needs the team to work on something else, they should inform the PO who would then prepare stories or Product Backlog Items for the next sprint.
You're right, I couldn't find anything specific about how the Scrum Master protects the team from external influence, specifically management. It seems like a glaring omission.