Sprint planning - client would like to add more important stories than the capacity allows. How to explain client that is not possible?

My question is how to calculate the estimated stories included in the sprint and how to explain to the client that it is not possible additional stories to be added to the sprint?

Why would you do that, and why would the client care?

The point of a Sprint is to meet a Sprint Goal which mitigates a significant risk or uncertainty. It's up to the Developers to estimate their Sprint capacity, so achievable goals can be identified and then accomplished.

Although potentially helpful for the team, the capacity estimations are not particularly relevant for communicating with the stakeholders.

The stakeholders must understand that the Developers and the Developers alone control what work goes into a Sprint.

The Product Owner, acting on behalf of all the stakeholders, is accountable for ordering the Product Backlog. All the stakeholders need to respect any of the decisions made by the Product Owner.

Sprint Planning can be viewed as a negotiation between the Product Owner, representing the various stakeholders, and the Developers. The Product Owner wants to maximize the team's value delivery throughout the Sprint. However, the Developers are under various constraints, including their time or capacity to take on work, their knowledge and skills (of the domain, the tools and technology, and the product under development), the quality and levels of technical debt in the product, and more. Figuring out what can be done and what makes the most sense to do is a key discussion at Sprint Planning.

The stakeholders should be more interested in the Sprint Goal, which represents the value proposition that the Developers are committing to achieving within the Sprint, and how that Sprint Goal moves the product closer to attaining the Product Goal. They should trust the Product Owner to represent their interests and balance the competing interests of various groups when collaborating with the Developers along the way.

Why is it your responsibility to do this?  You didn't mention what set of accountabilities from the Scrum Guide you are fulfilling: Scrum Master, Product Owner, Developer?  

Regardless of my first question, you are planning Sprints completely wrong.  The capacity is what the Developers believe they can work.  The output of a Sprint is not 296 hours of work.  It is a useful increment of work on the product that the stakeholders feel is valuable. The Sprint Goal is the commitment made, not a number of stories or total amount of hours worked. The Product Owner represents the stakeholder's needs to the Scrum Team. The Product Backlog should be ordered in a manner that shows what work is most important and makes the best use of the Developer's efforts. The Scrum Team will decide on a Sprint Goal and then the Developers will pull in Product Backlog Items that support the ability to reach that goal. The plan will be adjusted on a daily basis during the Daily Scrum and the contents of the Sprint Backlog will adjust in a way that allows the Developers to reach the Sprint Goal. 

That's my Scrum Framework answer. Here are my practical answers.

Another way to do this is to forget capacity planning and start using the actual past to justify.  Cycle time, throughput and cumulative flow metrics are a better way of showing how much work the team is capable of doing in a specific time frame.  Check out these books by Daniel S. Vacanti.  Start with "When Will It Be Done".

Explain to the stakeholders that the team is not able to work more than 40 hours a week without approval from them and your management. Also inform them that there could be additional costs associated to the overtime. Ask them what items that are already in the Sprint Backlog they would be willing to sacrifice for the new items they want to push in.