Generally, I think the development branch with feature branches tends to work well and scale decently, but I have some concerns that the process you describe is introducing some risk that can be avoided.
First, work should be merged more frequently than once at the end of the Sprint. Maybe for some extremely complex work that is difficult to decompose into smaller, deliverable entities, it can happen from time to time. It may also be more likely in shorter Sprints that the work is done later in the Sprint.
Second, all of the testing should be done within the context of a Sprint. In Scrum, a Sprint results in a potentially releasable product increment. However, in your current state, it takes you two Sprints to have a potentially releasable product increment. In a few environments, independent quality assurance is needed, but in that case, I would recommend rethinking your value stream and Definition of Done to align with how the work actually happens.
Overall, it seems like you don't have a lot of test automation. I would want to increase test automation to reduce the time it takes to get feedback. And this is at all levels, from unit tests on particular methods or classes to automated acceptance tests that simulate human interaction with your application. If you can run these on a regular basis, you can get feedback on if a change introduces a problem before you merge it into the development branch.
Finally, I don't think your ultimate question of determining which team's code "caused damage" is necessary to ask. This is a side effect of having long feedback loops, instead of short feedback loops. And even so, the team that introduced the problem doesn't matter - in a scaled instance, all teams are responsible for the quality of the product. If an issue is found, let the teams pull it into their work based on their understanding of the problem and confidence in fixing it.
