Ideally, this should be addressed at Sprint Planning. Determining "what can be Done this Sprint" is one of the topics to address at the Sprint Planning. This what is not only in terms of scoping the Sprint Goal, but also a broader set of Product Backlog Items. The Sprint Goal may be achieved by completing a very small number, perhaps only one or two, Product Backlog Items. If the team reflects on their past performance, forecast capacity, and the current state of the Definition of Done and finds they can select more Product Backlog Items into their Sprint Backlog, they should.
In order to maximize the chances of meeting the Sprint Goal, I've found it useful to look at the team's projected capacity and then reduce it. There is some data from Capers Jones in Estimating Software Costs, 2nd Edition, that uses "1 work month = 132 work hours". Traditionally, 1 work month is counted as 160 hours. Jones' work month is about 82% of a traditional work month, which is designed to account for paperwork and other overhead. In the absence of organizational data, I prefer to use a smaller numbers using 70-75% instead. The team should ensure that their Sprint Goal can be achieved in 70-82% of their forecast capacity. If not, the Sprint Goal and the associated Product Backlog Items should be narrowed.
If, during the Sprint, after selecting enough Product Backlog Items for the full Sprint, the team has met the Sprint Goal and all of the selected Product Backlog Items are Done, it's up to the team to decide what to do.
I'd be hesitant to pull more work from the Product Backlog. The ordering of the Product Backlog may change as a result of the Sprint Review, which would make any unfinished work not only "spillover", but also waste if it's not done. If this is selected, the Product Owner can help pick something that is likely to still be at the top of the Product Backlog at the next Sprint.
I'd focus on things that can help the team's performance. Refining work in the Product Backlog. Process improvements that need the Developers' attention. Identifying and quantifying technical debt that may be too big to just fix. Finding ways to improve the Definition of Done, which may require some kind of technical enablement to make it efficient. Learning new skills to become more cross-functional.