Differentiating Between the Team-Level Critical Path vs. "Hidden Work"
There really isn't any such thing as a "standalone story" in either SAFe or Scrum. In general, all work should be related to PI Objectives at the Agile Release Train level in SAFe, or the Product Goal, Sprint Goal, or Definition of Done in Scrum. Since teams in SAFe are using ScrumBut (see the Scrum Guide's End Note), SAFe teams aren't exempted from the need to tie work to a coherent Increment each Sprint.
However, lots of things can end up on the Sprint Backlog that are needed but not clearly tied to a particular high-level objective: architectural runway, chores, or other items too small to defined at the Program Increment level. In my experience, they can still usually be tied to Features, Objectives, or Goals, but in a few cases they are simply small but necessary items that only go on the Sprint Backlog because they aren't work items anyone outside the team would understand or care about. They're just necessary things for the team to do in order to complete or perform other work. However, such items still consume team resources, and should absolutely be made visible and transparent to the Product Owner, the Release Train Engineer, and anyone else who needs visibility into the team's available capacity through the Sprint Backlog whether or not they belong on the PI Planning board as separate elements of the critical path.
That said, please avoid adding anything that might be considered "hidden work" to your Sprint Backlog. If it's work, it belongs on a backlog. If it's essential work that impacts anyone outside the team or the team's current critical path to the Sprint Goal, then it needs to be explicitly included in the Product Backlog, the Definition of Done, or some other higher-level tracking artifact. No invisible work, ever!℠ is one of the many laws of CodeGnomism, and I thank you for providing such a great use case for explaining why.