What about just at first giving QA the authority to unilaterally revert commits in the event they cause QA violations?
Assuming that a QA violation is clear and evident, it seems reasonable to allow it to be reverted immediately without further need for deliberation, since introducing a QA violation could be construed as a regression.
If this is done it has the immediate benefit of prompt limitation of damage and goes directly towards what I think is QA's mission.
I'm assuming it's implied that an erroneous revert is itself actionable as dereliction of duty by QA.
Letting QA handle the immediate task of protecting/maintaining quality standards in the ebuild tree seems the right move.
Whether the offending developer should face disciplinary action for violating QA in the first place IMO should be a separate issue.
A possible idea is to let QA make a referral to proctors and/or comrel as necessary. For example, for the offending developer's actual QA violation a warning might be issued by proctors. A developer who shows a pattern of negligence, or who deliberately overrides a QA revert, or otherwise aggravates the situation beyond a proctor-level concern could be referred to comrel.
The general idea is to let QA take preemptive action as necessary to protect or undo any damage caused by a QA violation, since the tree itself needs protection that may well not benefit from waiting for social procedures involving discipline, and have any disciplinary matters handled as a separate issue possibly with a referral to proctors/comrel.
But the gist is having discipline treated as a separate issue that can be handled with social procedures and break off the actual QA task so that the tree's integrity doesn't wait for deliberation.