My insights for you. They represent one way. There are many ways, though (I say this to suggest there is nothing critical in my response… things can get sideways easily over text/documents).
I consider a “spike” to be a clever name for learning. I also believe that programming is mostly, say ~90%, thinking about what decision to make (of many options). The goal is to use software in that decision, as only then can we truly know what we need about the work. Thus, a spike is time for a team to perform thinking, some programming, and experimentation, to agree on a decision.
A spike given to a person to do research smells like “lead programmer” behavior, coupled with the decision making process confined to a single person. The collective knowledge of the team is not leveraged. A wiki or “report” to the team is less effective in conveying knowledge, compared to the experience of working on the code.
Regarding your last point, I may have misunderstood. I interpreted your scenario as all the work “in testing” at the end of the sprint with “developers” free. If that’s not the case and you have a few days open, can a backlog item be sliced to complete it?
If not, I don’t see the value in starting it. After all, unless you’re releasing continuously in a sprint, starting work now won’t cause it to be released any sooner (it will still be “done” at the end of next sprint). While, if the former, I question why you’d work in sprints anyway
If an item can’t be sliced, practice it with intent to finish. We can always slice… but it’s a skill that requires practice and discipline. Else, why not do some refactoring, or look back on your automation for the sprint? Heck… do some side projects for a couple days, then. I’d rather have a team with 100% energy going into a new sprint, rather than 99% energy.
Again, this is just one way, though.