100% user story completion vs 100% productivity
Think in terms of value delivered vs utilization. Goal of Scrum team should be to maximize output and not maximize utilization. Anything (whether a machine or person) working on 100% capacity for longer duration will eventually break.
The goal of Scrum is not to achieve the highest resource utilization; it is to achieve the highest throughput of completed, deliverable value.
Full utilization concept may fit well in the traditional project management domain. However, software development is usually not a predictable / well-defined process, it is more of an empirical process in which you may end up in a situation where you have to discard a full days worth of work and restart from scratch. People have to attend meetings, answer to support calls, etc. in addition to writing code. So it may happen that a story gets completed earlier than estimated (or may get delayed too).
Maximum utilization can be counter productive
You should push back on 100% utilization part because maximum utilization can be counter productive in software development.
Scrum is about transparency and setting correct expectations. Stakeholders need to know when a particular piece of value will be delivered instead of how many hours of a developer were spent to complete a story.
What to do if you find idle time
I agree with the fact that sprint backlog should be completed some time before the sprint end date so that it can be tested and team can finalize a stable build after the required bugfixing etc. So developers may fix issues which were reported during testing within the current sprint. In case the team consistently performs well on the QA front and not many bugs come up then you may reduce this sprint end testing time and in future sprints the team may add more stories to the sprint backlog.
In cases where the team finds some idle time, the team may consult Product Owner to pick a story from product backlog which is next in line or can be completed in the remaining sprint time. Alternatively, if there are technical debts to pay then the team can also work on those.
In case of stories being carried over to future sprints, the Scrum team should not be held responsible for stories which were not part of the sprint backlog to begin with.