Most of this answer is theoretical. I've included what may be the crux of the issue at the end. But you should probably read the whole answer.
According to the Scrum Guide:
The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”
So the first question: is the increment always releasable?
If not, why not?
If it is, what is this concept of "clean up"?
Whether or not the stakeholders and Product Owner agree that the changes in the Increment are what they wanted, they are there.
It may be that the Product Owner does not want to release until a future Incremement is provided, but as long as it is releasable, the Product Owner should accept the increment.
If not, then the Product Owner and Development Team should work out whether anything from this Increment is salvageable, and the Scrum Team (Product Owner + Scrum Master + Development Team) should work to understand how the Development Team didn't manage to deliver a releasable Increment.
Not having a new Increment is far from ideal, but any wasted effort is restricted to one Sprint at most, and new insights and opportunities to improve will have been identified.
So the issue is really one of whether the Development Team have undone work in the Increment (e.g. newly broken functionality, or untested/undocumented features that are merged but don't meet the definition of "Done"), or whether they have unfinished work, which is that they have delivered some of the required feature(s), and the product functions in a way that is acceptable, but not as good as stakeholders hoped.
If undone, then the Increment is not releasable - treat as explained above.
If unfinished, then assess what future changes are required/desired, and have the Product Owner add them to the appropriate place in the Product Backlog, then allow the Development Team to estimate the new items.
Just because there was some previous expectation of delivery, the Development Team must start and end the Sprint with a releasable Increment. Taking this Increment, the Development are only likely to be able to do a certain amount of work. Be empirical. Use previously gained knowledge to work out what can be done, and the Development Team should be able to forecast what it can deliver in the next Sprint (note: the Scrum Guide now refers to Development Teams forecasting, rather than committing - that's just being realistic).
One Sprint that delivers less than forecast is not a reason to expect the next Sprint will deliver more. If something limited the team's ability to deliver a certain amount last Sprint, unless that issue has been identified and resolved, there's no reason to expect the team to deliver more the next time.
Whatever happened, use the Sprint Review in a way that enables the Scrum Team and Stakeholders to minimize the risk of this happening again. Use the Sprint Retrospective to establish new ways of working, and potentially a change to the definition of "Done" to minimize the risk of it happening again.
From your question, I actually think the real issue (which you would probably also identify from using Scrum strictly) is that your Development Team is not responsible for QA. Not all members of the Development Team need to have the same skills (they don't need to be a "Developer" as such). The team needs to be able to do everything that is required to produce a "Done", releasable Increment. The logical step might be updating the definition of "Done" to include QA, and including QA engineers within the Development Team, and potentially adjusting tooling/systems to support this way of working.