Stakeholder Management is Mostly the Product Owner
The Scrum Guide is largely silent on issues of stakeholder management per se, although the Product Owner's role of managing the Product Backlog strongly implies that the Product Owner (PO) is primarily responsible for managing stakeholder requirements. Managing stakeholder expectations, on the other hand, is definitely spelled out as a PO responsibility, especially during the Sprint Review. In addition to working with the stakeholders to develop the Product Backlog, the Product Owner is responsible for:
- Inviting key stakeholders to the Sprint Review.
- Explaining what Product Backlog items are "Done" or "Not Done."
- Discussing the Product Backlog as it stands.
- Projecting likely target and delivery dates based on progress to date.
Of course, the Scrum Guide also says:
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
Contrariwise, while the Scrum Guide says that the Scrum Master is to help "employees and stakeholders understand and enact Scrum and empirical product development", the responsibility for stakeholder communications and management are not explicitly assigned to the Scrum Master role.
In practice, stakeholder management is usually a Product Owner responsibility, but there's nothing prohibiting a team from reallocating the work (as opposed to the accountabilities for each role). However, I'd consider a Product Owner that abdicates personal responsibility for stakeholder communication to be a framework implementation smell.
Your Process Lacks Adequate Customer Collaboration
The values and principles of the Agile Manifesto argue strongly against your current implementation. The Sprint Review is meant to be a collaborative exercise that includes the stakeholders, not a meeting that results in an indirect report to be forwarded to stakeholders. The Scrum Guide says:
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
In addition, the Agile Manifesto and its principles include the following items:
- Customer collaboration over contract negotiation.
- Business people and developers must work together daily throughout the project.
- The most efficient and effective method of conveying information to...a development team is face-to-face conversation.
Client notes, post-Sprint validations and sign-offs, and "summaries and screenshots" instead of Sprint Demos are all giant red flags that your process is not adhering to either the Scrum framework, or to the agile values and principles. Your team, your organization, and your stakeholders should all carefully re-evaluate whether you really want to commit to an agile process based on real collaboration, or whether someone just wants to cloak a more traditional project framework with a few loosely-applied Scrum ceremonies.
Is it the substance that truly matters, or just the appearance? Based on your description I'd bet good money on the latter, but your mileage may vary.