What do you do if there is some spare time left in the Sprint?

Occasionally, a team may find itself having finished all the stories it had committed to in the current Sprint - and still with some free cycles to burn before the Sprint ends.
Yes, I know, with the stories being fine-grained enough, and the team members being good with the estimations and planning (let's not forget the execution too!), this situation wouldn't be too common... But still, this may happen.
The stars aligned, the integration went miraculously smoothly, the architect had an epiphany with an elegant and easy to implement pattern... Doesn't matter. The bottom line is that the team suddenly ends up having some 2-3 spare person-days in the Sprint.

Initially, my concern was that - in theory - according to the "dogmatic Scrum" (yes, I'm aware that this is an oxymoron :-)), the Sprint content is supposed to be locked once the planning stage is finished, and the team has committed to deliver the certain set of stories.

But then (thanks to Chuck van der Linden's comment) the understanding "hit home": this should only refer to *external* attempts to modify the Sprint content for the team; it is perfectly fine for the team itself to pull more stories into its iteration!

So, how would (or should?) the team utilize this capacity?

With Scrum team's being self-organizing, the decision should ultimately be the team's.

The options for the team to choose from seem to be:

1. Maximizing the value delivered to the customer. After all, this is what's going to pay the bills, right? ;-)
   Normally, the most obvious way to do this would be to go back to the PO and to ask for the next backlog story with the highest priority - out of those that can fit into the team's spare capacity.
   Ideally, that new story will be committed to by the team, and delivered by the end of the Sprint together with the rest of the stories previously committed to.
2. The second suggestion is pretty much the same as the first - but with the option to have a larger (yet still the highest priority) story picked up, having the work on it continued into the next Sprint.
   Since the team velocity should be calculated as a moving average across a number of Sprint, it wouldn't really matter if working on this story gets accounted for in the current Sprint or in the next one.
   The problematic thing with this approach is that it blurs the concept of a clear commitment to having all the stories "done done" by the end of the Sprint. With Scrum, the team should never knowingly commit to a story it will obviously not be able to complete within the same Sprint's time box. Starting a story in Sprint N and carrying it over to Sprint (N+1) clearly undermines this idea. I'd risk suggesting that if the team finds this happening all to often, it should re-evaluate whether what it follows is Scrum, or Kanban, or some sort of their hybrid combination; by the way, either is OK, as long as it's wittingly decided upon, and not just happens.
   Some sort of a mitigation to this concern may be in breaking the original "extra" story into two, by chipping off a "spike/investigation/prototyping" story (that can be completed in the current Sprint), and leaving the "implementation" part for the next Sprint. I can see how this would be perceived as cheating... ;-)
   On the other hand, though, if the story could be broken into 2, maybe it should have been broken down that (or some other) way in the first place?..
3. Yet another variation of the first approach would be to identify (and task out) a few "extra stories" during the initial Sprint planning, so that when/if the team runs out of work it will clearly know what's next in the pipe.
   Worst case - these stories will just be worked on in the next Sprint.
   My only objection to this technique is that it "smells" with a possible indication of team's inability to properly estimate the amount of work it can complete in a Sprint.
4. Fix bugs injected by System QA as a result of testing the previous Sprints' deliverables.
   If these bugs were sufficiently prioritized (by the PO / QA triage), they will have to be addressed anyway; why not to do so earlier, if the PO is OK with that?
5. Perform some minor refactoring (remember, there's not enough time for a major one).
   This may be either an ad-hoc activity, or driven by the Technical Debt backlog (it's always nice to have more of it repaid, on top of the 10-15% of the Sprint time that should be allocated for working on Tech Debt anyway).
6. Work on improving the quality and/or quantity of the unit / automated tests coverage.
   There doesn't necessarily have to be a problem with the Definition of Done; if it defines (among the rest), let's say, over 90% unit test coverage - the stories may be claimed "done", yet there still will be space for improvement (bringing that coverage to 95, or even 100%, where feasible).
7. Have the developers assist QA in the validation of the stories' "doneness".
8. Give the team carte blanche - play with new technologies, read books, listen to webinars, go home...
9. Go out, have some team-building activity.
10. All (or some) of the above.
11. Other?

The original discussion can be seen here (LinkedIn "Scrum Practitioners" group membership is needed to see the page).