Product Owner who is a client coming up with new story in the middle of the sprint

At Sprint Planning, the Scrum Team creates a Sprint Backlog - the Sprint Goal, a set of selected Product Backlog Items, and a plan for achieving the goal. The Developers are responsible for managing the Sprint Backlog and no one is supposed to tell them how to modify it or how to go about executing on the work - this is a characteristic of a trusted self-organizing, self-managing team.

In the event that the Sprint Goal becomes obsolete, the Product Owner can cancel the Sprint. However, I don't often see this used since it's quite disruptive to the team and external stakeholders receiving deliveries from the team. Operating in a scaled or multi-team environment only adds to the disruption of cancelling a Sprint.

As the Scrum Master, there is probably room to teach the Product Owner good product management techniques. Asking why this particular change can't wait for the next Sprint, especially to make sure that the team can refine the work and come to a good understanding of what is required before starting it is a good first step. Understanding the relationship between the Sprint cadence and the release cadence could also be useful. Making sure that the Product Owner understands the value in the predictability of the Sprint cadence and the risks of disrupting the team may be helpful. If this is a common occurrence, I'd look at two aspects - the Sprint cadence and the ability of the Product Owner to identify and order work for the Product Backlog.

If the product owner who is as well a client is adamant that she would want a new story to be worked on in the middle of spring which is practically not possible to accommodate and can effect existing sprint as well. How to handle this situation as scrum master.

The Product Owner ought to be as committed to the Sprint Goal as any other Scrum Team member. It sounds like this new piece of work would put the Sprint Goal in jeopardy. As a Scrum Master I think I'd wonder about that and encourage her to further develop that train of thought.

My practice is that as long as the change will not endanger the Sprint Goal, a conversation ensues in which the Developers and Product Owner discuss changes to the Sprint Backlog to accommodate adding the new item.  This usually results in other items being removed from the Sprint Backlog.  If the addition will endanger the Sprint Goal, discussions ensue about whether to cancel the Sprint or save the item for a future Sprint,

The Scrum Guide states: 

The Sprint Backlog is a plan by and for the Developers.

The Developers own the Sprint Backlog and it is developed with the intent of satisfying the Sprint Goal.  

The Scrum Guide provides this list of services the Scrum Master provides to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

• Helping find techniques for effective Product Goal definition and Product Backlog management;

• Helping the Scrum Team understand the need for clear and concise Product Backlog items;

• Helping establish empirical product planning for a complex environment; and,

• Facilitating stakeholder collaboration as requested or needed.

This is an opportunity for you to serve the Product Owner by helping them manage the Product Backlog (where this item should currently exist).  

The Scrum Guide also states this as a service that the Product Owner 

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

As a Scrum Master you do not "handle the situation".  You help others handle the situation.