The idea of a required code review before it ends up in a shared branch is a good idea. Of course, the people who are doing the code review should be the people with the knowledge of the system under development (including the requirements, architecture, and future direction) rather than just any team members. It doesn't make much sense for a brand new hire to be assigned to do code reviews and be able to merge that in, unless they understand the larger context.
The idea of passing a code review along doesn't make that much sense to me, though. If there are a small number of more senior developers, then those people should be the ones doing the code reviews and merging, along with mentoring and coaching the less senior developers to help them get to a higher level of knowledge. As more people gain experience and knowledge, more people can be given the responsibility of conducting code reviews and merging the software.
I don't think that Scrum is going to offer you any guidance, but Lean Software Development will. Both context switching and motion are wastes that, in a lean environment, should be reduced or eliminated. In your current state, you have one person who needs to switch contexts and do work. In the proposed future state, you have two people who need to switch contexts as well as pass messages between each other.