"Violations" of the Scrum Guide in a team/project

Hello,

I've started my Scrum Master journey with a team a month ago. So far I tried to observe and not try to change too much (this is one of the hardest aspects of the job, when I have so many ideas! Not gonna lie, probably my biggest personal challenge right now).

However, there are a lot of aspects that are not done within the framework provided by the Scrum Guide, but which seem rather waterfall-y. These include:

1. Stories (not Items) are based on developer roles (front end, back end, UX...), and while they are sometimes tackled by more than one developer (I use the word "developer" in the sense the SG uses it), sometimes a story can't be done within a sprint because of blockers; those team members then work on other topics instead, because...
2. there is no Sprint Goal (also no distinguishable Product Goal), so no shared commitment of the team
3. Several of the Scrum Events aren't done in the way they are meant to be done (at least in my understanding): The Daily is more a status meeting (and who can blame them? If there's no Sprint Goal, how can the team come together to discuss what's necessary to reach the Sprint Goal?), the Review is a demo of "work done" (and "work" often times does not mean value delivered to the customer); the Refinement (not a Scrum Event per se, I know) is not a discussion/conversation about how items need to be split, but rather "does this story have enough AC and does it have Story Points"

Now I'm having a hard time deciding what to do for more than one reason: First, the team is discontinued by the end of the year, so motivation is at a low point, and there's not much point in improving - to what end anyway?

Second, the whole project setup is...difficult to say the least. My company (or at least this branch) uses SAFe, and it's been pointed out in other places that SAFe brings a lot of rather unagile aspects with it. Some I could already figure out:

1. There is no single PO, but a collective, and it's unclear to me whether any of them is the PO of the rest, or whether they're all on the same level; in theory I'm a fan of less hierarchy, but it's hard to figure out whom to ask for priorisation
2. Budgeting is in the hands of "the leadership", so it's almost certain that the same thing will happen to the next teams (I'm already set up to be Scrum Master in two teams beginning next year); also, it's almost given that whatever any of these two teams can achieve by the end of next year, they will be dismantled and the team members distributed over other teams again.

So my question:

As a beginning Scrum Master, what should I concentrate on here? Since I'm practising my observing skills and not interfering where it isn't due, I'm thinking of simply making notes on what I recognise, then trying to figure out what the reasoning behind these behaviours (both with management/leadership and the teams) is.

Would love some pointers and insights :) cheers!

Alex