That will never be how it's done. You work on it however long you can on this sprint and then finish it in the next one. So now you have two choices: either break it down in a completely arbitrary way into two stories, one for each sprint. Or just completely ignore the sprint boundary nonsense and just work on it.
Either way, it highlights how dumb it is to put silly boundaries on work delivery. Accomplishes nothing other than to waste people's time.
It works because your stakeholders see that you're actually delivering what you said you would _when_ you would, and that gets you the buy in and authority to run the team in a sane and sustainable manner.
For what it's worth, I prefer Kanban in most cases - but both are just different ways of managing WIP, utilisation and delivery time.
However, your example is unrealistic - you wouldn't split that task into two. If it won't fit comfortably in the sprint it waits for the next one.
It varies hugely by team and process, but where scrum/sprints are a good fit a reasonable first level of sprint loading seems to be a limit at about 70%. E.g. if an engineer has ten days available to work in a sprint, no more than 7 days of estimated work are pushed their way. The other 30% is assumed to be code reviews, meetings, pairing, bugfixing etc.
If that 70% is too high or low, it can be adjusted.
For everything else, there's Kanban.