...
Grow the pool of confident PR reviewers
clearly document two levels of review:
first level review to capture obvious problems and provide feedback;
second level review by product owners/tech leads and others with a lot of experience in the code
Add tags for time expected for items that would contribute to maintenance
Build a culture of welcome and positivity for new contributors: make PR review better by being more positive and going a little way out on a limb to get the first one or two in. Shift the mindset from "why should this be accepted" to "how can we help you get this accepted".
identify the major functional areas (e.g. collections, search builders, presenters, etc.)? Then developers can build expertise in a functional area, allowing them to feel more comfortable reviewing PRs in that area. First step would be to list out the functional areas and then identify a 'functional lead' for each area. This would reduce the cognitive load of trying to understand all the components.
Newbie group/office hours in 1/2 hour before the before the tech call: experienced Community technologists give a demo or lead a discussion on a topic
...