How to handle when Developers have bandwidth but QA cannot complete user stories?

This is a case where, as a whole, the Scrum Team is cross-functional in that the team members have the skills necessary to complete the work, but the individuals on that team are not necessarily cross-functional and are organized into sub-teams. Focusing on developing cross-functional skills on an individual level and organizing to get work to meet the Definition of Done will help.

There shouldn't be a distinction between "Developers" and "QA team". This doesn't mean that you won't have specialists. However, it means that people with specialized knowledge and experience in a particular area collaborate with others on the team to share their expertise. This way, when a specific skillset is in high demand, non-specialists can contribute.

I’m facing a situation where our Developers have bandwidth to pick up more user stories, but our QA team is unable to keep up with testing and completing them within the sprint. This is leading to stories being partially done and spilling over.

I don't think it is. It's just exposing that the Developers -- and they include QA testers -- are unable to frame and meet Scrum commitments. These commitments include a Sprint Goal which would make the selection of work coherent in the first place, and a Definition of Done which would ensure that each Increment is of usable quality.

Instead, individuals are just sawing away as best they can at a backlog of stuff. That's what's causing work to be "partially done" and "spilling over".

So, Ian, if coaching developers is not doing the cut, then I guess that SM as a Scrum Project Manager (Schwaber Agile Project Management With Scrum 2004, which was never denied or overwritten) should actually enforce some rules to deliver to his/her's clients, right?

Right?

And please provide me a binary answer, not Socratic method questions.

The latest version of the Scrum Guide says:

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

So rather than enforcing rules, it might be better to think of a Scrum Master as enforcing people's understanding of the rules. To the extent that a Scrum Master is a manager at all, they manage people's understanding of Scrum.

Scrum Masters should coach principles, not enforce rigid rules. Rules are black-and-white do’s and don’ts directives, but principles guide the team to make better decisions while keeping autonomy and adaptability.

In this case, the principle is that the whole team is accountable for getting work to “Done,” not just Dev finishing code and leaving QA with a bottleneck. Practical ways to encourage this:

• Encourage cross-functional collaboration (e.g., Devs help with QA automation).
• Keep stories small (2–3 days dev work) so QA can start earlier.
• Scrum only counts fully Done work — a few finished stories beats many half-done stories.
• Swarm on finishing before starting new items — whole team should help finishing stories off.
• Use transparency and openness to expose structural issues, not hide them with velocity tricks.

It is fine to look ahead to the next Sprint, but the principle is to finish as much as possible before starting more. That way, the team learns to finish together and deliver true increments, not just “Dev complete” work.

There are two elements in this question. First about what you call bandwidth, which is very well manageable by using Little's Law to manage throughput, cycle time and work in progress.

Second: please remember that team is not in a job of producing story points. They are completing actual increments. It means parts of the product which have actual, not imaginary value. Story points are just a made up technique to monitor progress during the sprint, once they burn down they don't exist.

Story points are estimation(hunches) of effort, not the volume of work. If your team is struggling with a scope of work for each sprint, then trying some scope based estimation like Monte Carlo estimation or Scrum with Kanban -which includes Little's law might help drawing stoppage lines and limit the flow of PBI'(you might call them user stories judging by the approach) into the Sprint backlog.

You can learn more about Monte Carlo  probabilistic estimation here: https://www.scrum.org/resources/forecasting-techniques

And about Scrum with Kanban and Little's law here: 

https://www.scrum.org/scrum-kanban

Enjoy learning