Having people blame the latest deployment is only natural. And the fact an issue is found during testing on the latest deployment but your research finds the problem was introduced months ago doesn't matter. If the user just found it, their perspective is it was just introduced. You cannot fault people for having that opinion with no other facts. And if the user found the problem prior and reported it and you didn't address it, then many people will report it again and again wanting it fixed and this usually turns into them distrusting the engineers so they want to sit on calls to make sure you hear them.
As for having real time Skype type reporting of issues, this can go both ways but usually happens for a reason. I personally prefer they produce a document with their first cut of issues, and then we look at them and get on a quick call to go over it and then if we see something isn't clear we can walk through it right there. Usually when they do this as a rule, there is either a past history where they felt engineering didn't listen or they feel they have to be directly involved or things aren't getting done.
Non-technical Product owners is the norm in most enterprises and as companies grow you will almost always have non-technical product management. Some are better than others, but part of the job of engineers is to manage those relationships and expectations. That is partially why senior engineers or team leads are paid more and have advanced further, they know how to manage the business side of the tech job better. Not that they like it, but they get it and do it.
If you want the person to stop doing real-time reporting, give them a way to report issues clearly and in a way that makes them feel in control and that you are listening. For example, give them a simple (not complex) template to fill out for the defects, and then setup a meeting with them in two days (or some short timeframe) to go through everything they reported and give them an update. That meeting may only be 20 minutes for you to walk through each defect with them verbally and see if there are any questions or follow ups and for you to categorize the problem for them. But doing this makes the product owner feel that you are listening and that you understand which is most of the reason I have found they like to try and report on a call in real-time etc. You categorizing the problem is part of what they usually are wanting, e.g. low impact to high impact, it doesn't mean giving timeframes until you have time to investigate more, but telling them this is a complex problem versus a simple problem helps them feel good about what is happening.
99% of tech to business is learning to communicate in a language the other side understands, and I don't mean treating people like they are stupid, I mean putting it in terms that helps them understand how it impacts them. For tech to business, it is in terms of time, money & complexity. Complexity being the biggest because if they ask you for a fix but it only affects 5% of clients but it will dominate the schedule for the next month, they'll punt on it 9 out of 10 times to get everything else done first.
Managing the stress is learning how to communicate and understand what the product owner wants and giving it to them before they feel compelled to come to you.