Sprint Review day

It is a good thing that you are getting such feedback from stakeholders in your Sprint Review; however, it seems that there is perhaps a disconnect between your Product Owner and the stakeholders if the latter are identifying significant issues or missed requirements?

You should try to promote keeping the Sprint Review as late in the sprint as possible - it isn't a demo and patch session.   Any presented functionality should have already met your DoD and be production ready.   If there are issues around missed requirements or incorrect acceptance criteria, that should be a discussion in your Retrospective on how to improve those areas.   

I would not try to accommodate a "fix" session post-Sprint Review.   Allow your Product Owner to make the call whether functionality should be released or held back based on stakeholder feedback or identification of issues like downstream impacts.   Use your Retrospective to discuss any unexpected Sprint Review feedback to explore ways to mitigate/eliminate such negative results in the future.

How does the team currently establish transparency over:

• Work that is refined and “ready” for Sprint Planning
• Work that is Done and not Done

I've totally experienced this before, as I'm sure a lot of people have as well.

A few suggestions I have...

• Sprint end doesn't represent the Release date.
  • It's the day you take to get feedback from the people utilizing what you just made.
    • It's also the time for the team to reflect on what they just did and improve themselves for the next sprint.
  • By decoupling the release date you gain flexibility and reduce crunching.
    • You also gain ability to deliver exactly what is needed instead of what is done.
      • You could also set a release date to say the first Tuesday of the Sprint, giving the team the time they need to get it all done and ready, and support the deployment.
        
         
• You may have to spend time training the PO
  • They need to be the customer/stakeholder proxy, thereby having the ability to approve/disapprove stories as they are ready to be marked Done.
    • If they understand the cust/sh needs well, you get feedback much earlier in the Sprint and have higher successes for the Review.
    • You also could enable the team to deliver multiple times during the sprint, on a cadence. 
      • Instead of just first Tuesday, maybe every Tuesday it deploys to a Staging/Demo environment. It's all based on how well the PO understands the cust/sh. 
        • Then you could still push to production what's in staging without delaying release based on refactors.
          
           
• If your Sprint Review is based on the Sprint Goal/Objectives, you won't have to go story by story and diving deep into each.
  • It would then be done by discretion of the cust/sh.

We release a new version of our product into production after every sprint.

Why? Shouldn't you release new versions when it is appropriate to do so? And if information obtained in the Sprint Review determines the increment to be not ready then don't release. The Scrum Guide section on the Development Team states 

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint.

Notice the word potentially? 

Have your team read the section of the Scrum Guide where the Review is described (https://scrumguides.org/scrum-guide.html#events-review).  A couple of things I'd point out to them:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. 

...and the presentation of the Increment is intended to elicit feedback and foster collaboration.

• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. 

Anything identified as needed changes should be reflected in the Product Backlog.  

As @John Varela suggests, decouple the releasing of product updates from the Sprint Boundaries. I've had teams that took feedback from a Sprint Review held on the last day of the Sprint, created Product Backlog items, put those items into the next Sprint, finished them and pushed a new release of the product on the 3rd day of a current sprint. I honestly feel like that should address most of their concerns. 

As for the "you didn't understand the requirements" issue, point out the empirical evidence. Ask them why they feel there is risk so great that they need to change the way they work when the empirical data suggests otherwise?  When it does happen, you should inspect and adapt immediately which is one of the largest benefits of agile and Scrum time boxes. Addressing @Ian Mitchell's questions will help with this situation as well.  If the team is providing good visibility into their plans, some of those situations that scare the Developers so much can be avoided.

As Timothy mentioned, I think a conversation needs to be had with the Product Owner. The Sprint Review is about "here's what we have completed during the sprint", not "please check and approve what we have done".

Is there a way you could get the Product Owner to review what has been done during the sprint, as the team is working on it, or as part of the Definition of Done?

Any feedback that is found during the Sprint Review can be added to the Product Backlog for a future sprint, not the current sprint.