Thanks for an informative question - for someone like me who has never formally used Scrum as a method for software development. I am part of a product company - and we went from traditional waterfall to Iterative to what can best be described as Kanban - altho' Kanban by itself is not a software development method.
I am not trying to "sell" Kanban to you - having been around for over 25 years in the software industry, I am very familiar with the challenges involved in changing processes in a software organization! But I thought I'd share ideas from Kanban which you might have the flexibility to try in your team.
Kanban's key points are to visualize your existing process, limit work-in-progress (limit WIP), establish Pull and improve gradually (evolutionary change rather than revolutionary). Since you are already practicing some of these, the rest might be easy to adopt.
We have - and had - a very similar situation to yours - lot of regular feature development and defect fixing work as part of the regular product enhancements, that needed to go out in a release; interspersed with code refactoring and other Engineering driven tasks - and our challenge was visualizing it for everyone in the company so the CEO and Sales and Marketing knew exactly how much work Engineering was handling, and allow them to weigh in on the priorities of all the work.
When we moved from an iterative process to Kanban, within a couple of iterations, our board looked as shown in the pictures shown below -
Our Dev process was mapped in the Dev lane of the Kanban board -
Our overall Kanban board looked like this, with the last lane being reserved for Engineering driven and other 'hygiene' work -
As you can see, we not only had a Dev lane and a Global/ Engineering items lane, but also some customer interrupts and a planning lane. Each lane also specified how much total work could exist in each lane - the WIP limit for that lane. Developers would take up (pull) work in the Global task lane whenever they had any spare capacity. Once they pulled it, they would typically finish it before taking on a new user story.
This allowed us to map and visualize our situation exactly as it was - whether we liked it or not, a high-priority customer interrupt did delay or shift work on other items. Instead of trying to map them as user stories, we mapped each type of work as is - and pushed work out to Staging and Production as it became ready. The normal process we used was to include some of the engineering stories/ tasks ever 3rd release or thereabouts.
The beauty of this system was that it helped us study the volume of work in each category (Kanban calls it "class of service") and reorganize our board, our process, and the team as we went along. Within one year of adopting Kanban, we made a production release almost every month - which made our Sales and CEO - and our customers very happy of course! And of course, doing this meant that we automatically had 'official sanction' from the CEO and Product Management - recognition that this work was important (but not necessarily urgent) - and needed to be done whenever there was spare capacity available to do it. Of course, there were times, when with the help of Prod Mgt, some of this work got specifically prioritized due to its urgency.
So, if possible in your environment, I'd suggest that you have a frank discussion within the team - and with any stakeholders that need to be involved - and work out a method that helps you map your current work and process - and helps you arrive at agreement to prioritize some of this work on a regular basis - and package them in the first possible sprint/ release that you can. In the process, you might find yourself doing somethings that are not necessarily "true to Scrum" - but might help you evolve to a better process that allows the team to work much more smoothly than it perhaps might be doing today.
Apologies for a long response, but I hope it helps. And again, this might not be a direct response to your question - but I hope some of these concepts might be useful for your situation.