Self organizing is not an automatic statement about a SCRUM team. You don't get it simply by using SCRUM. The goal is to get to that point, and SCRUM's advocates claim that it helps you get there.
The self organizing concept is tempered by a key line from the SCRUM guide
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
While the development team is free to choose how to approach the work in the backlog (self organizing), they are accountable for completing the work. SCRUM says that leadership should not assign accountability/blame to any one team member, but they can assign it to the team as a whole.
If there is a major division in the team, but they can still be held accountable for getting the work done, that's just a particularly pathological version of a self-organizing team. And, of course, SCRUM won't recognize that particular division, but the team is welcome to be divided.
If they are not succeeding, then the team is held accountable. The SCRUM guide offers no guidance at all as to what this means. It's a case-by-case sort of thing. But it would certainly be reasonable for leadership to dissolve the SCRUM team and switch to another development model if SCRUM is not meeting business needs. Or, perhaps less drastically, implement an almost-SCRUM that includes some heavy handed forces on team dynamics to resolve a business concern. Maybe, after it is resolved and people's emotions are repaired, they can transition back from almost-SCRUM to true SCRUM.
I would hope that there would be substantial attempts to rectify the situation first. If you read between the lines on the Product Owner and SCRUM Master's jobs, you can see that part of their unofficial job is to help resolve these sorts of things before the team fails to accomplish their mission. Indeed, the Product Owner is identified as being accountable for the development effort as a whole, so they are on the hook to make the development happen.
Fundamentally, this is where the line between procedure and people sits. Good leaders know that they have to work with people, not just procedures. If your Product Owner and SCRUM Master are good leaders, they will already be trying to help you resolve this. If you have a team of aspiring good leaders, they will hopefully be trying to learn how to resolve this.