Barnaby Golden, Thomas Owens, and David Espina have all given good answers, but I want to address your core question in a different way. You ask:
I wondered if anyone has any retro format approaches that would allow this dysfunction to surface from the team.
As the Scrum Master, it is your responsibility to facilitate respectful, courageous, and sometimes difficult discussions within the retrospective. Team working agreements, roles and responsibilities, and team communications are all topics that are well within the mandate of a typical retrospective, but it's your job to ensure that it's done constructively.
I realize that you're looking for a simple format for addressing the topic, and while I provide one below I feel like that aspect of your question is actually part of the problem. The general tenor of your original post already implies a strong judgment about the situation and the participants, and that is not conducive to holding a healthy retrospective because it sets up a Team-vs-PO dynamic that is likely to devolve into defensiveness and finger pointing.
Instead, if people are raising the issue with you in you role as Scrum Master or Team Member, then as a member of the team you're well within your rights to call out the issues that have been brought to your attention within the retrospective. Then, be sure to facilitate the discussion to keep it on track and constructive, and keep the team focused on walking away with a concrete plan or action item.
A Worked Example
The Scrum Master's goal isn't to assign blame; it's to facilitate continuous process improvement. With that in mind, an experienced Scrum Master might use the following format to uncover, address, and resolve a role- or communication-based process problem within a Sprint Retrospective.
Scrum Master Mini-Script
This Sprint a number of people have raised concerns about status reporting to the Product Owner reducing Development Team productivity as measured by...To address these concerns, I'd like us all to examine:
- Whether it's actually a problem for the team as a whole or for individual members.
- If so, what's wrong with our process, communications, or transparency that's triggering these what feels to them like excessive status pulls?
- Now that we've identified the issue, what are our action items as a team?
You can also use techniques like 5 Whys to identify a root cause, and make sure you step in firmly to prevent ad hominems or any attempt to ascribe evil intent rather than uncover a reason. Remember that the goal is to identify process problems, and then identify process-oriented solutions.
Okay, Then What?
As a further practical example, it seems likely that in this case the 5 Whys might identify a lack of Product Owner confidence in the Development Team's ability to meet the Sprint Goal, or uncover a less-than-transparent development process where the Sprint Backlog, Kanban Board, or other information radiators aren't reliable or aren't being used to best effect. Whatever the problem turns out to be, think of it as a process problem and find a process-oriented solution as a team that the whole team can get behind.
Adapting the team's working agreements and practices to solve process problems is at the very heart of Scrum, Kanban, and the Agile Manifesto. The roles, ceremonies, and processes that form Scrum are meant to facilitate effective negotiation of sustainable working agreements, and not to affix blame. Always make sure the entire team (and especially the Scrum Master) maintains a relentless focus on the process problems, not on finding individual fault!