Scrum and Legislation

If unexpected bugs are contributing to 15 hours per person per week, you can reduce overtime by not planning that much development work in the sprint and more or less reserve this capacity for bugs.

I conclude from your post (correct me if I am wrong) that these bugs are now put on top of the regular planned work.

In scrum the rule of thumb is more or less that if some work comes into the sprint after planning, roughly the equal amount of other work goed out of the sprint.

Your goal is to keep the team motivated and have them work in a continuous sustainable pace. Overtime can be a killer, a drainer, a burnout rocket, a wrecking ball for family and work-life balance.

Moreover, it reduces transparency on how much work the team can take on in s sprint, and it might drive expectations on team capacity which are incorrect. Also, predictability about things like velocity will suffer.

A PO can help accounting for these bugs beforehand and thus keeping room for it and manage this with PO stakeholders. SM can help by coaching teams and organization how overtime will reduce transparency, predictability and most importantly: health and work-life balance

So,limited time is left for completing project.

What PO and Scrum Master should do in this case?

In Scrum, each Sprint may be thought of as a project. There is always a limited time available for the completion of work. By the end of each Sprint a "Done" increment of release-quality must be delivered.

The presence of defects suggests that the level of quality may be inadequate and that technical debt may have been incurred. Rather than having the team work overtime on completing additional scope in further Sprints, it would be reasonable to focus on quality improvement, defect removal, and on ensuring that the deliverables already provided are indeed "Done".

I don't believe that the members of the Development Team - or anyone on a Scrum Team - should work more than standard hours. Any local rules, laws, or regulations aside, working extra hours, especially for an extended period of time, goes against one of the underlying principles of agility:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Working 55 hour weeks for a length of time is not "sustainable development".

I'd instead focus on the caused these unexpected bugs. Why were they allowed to be injected in the first place? What practices can be employed to detect them earlier or prevent them? How can we create better plans for our Sprint that account for uncertainty, like discovered work?

As a Scrum Master, I would recommend that the Product Owner work with stakeholders to adjust their expectations. The team should refocus their effort not on delivering new features or functionality but improving the quality of the entire product for the remainder of the Sprint. The Retrospective can be a good opportunity to inspect the team's way of working and the Definition of Done and make adjustments to prevent this situation in the future.

In the sprint week,scrum team realized that development team should work 55 hours in working days which that hours should not be more than 40 hours according to official legislation.

How much work development team can accomplish within standard legal working hours in order to produce releasable increment at the end of the Sprint which meets the DOD?