in some ways it's good that you're slow at the end of a sprint, that means your estimating well and not over committing, as far as keeping busy, on scrum teams I have worked on we always added research tasks for what's coming up next sprint.
This could be doing proof of concepts for things that are coming up, or looking at where to re-factor existing code, working on getting better test coverage on your code, etc.
Derrk,
1) All sprints can be halted at any time in reaction to things like the critical operational defects you mentioned. The reality is, no software development methodology would force you to ignore critical issues like an operational defect. If it did, it would never be implemented.
2) You can do this a couple of ways. As you mentioned, a defect-tracking sprint is one way of doing things. The reality is that under SCRUM you should always have a tester embedded into your team. Their responsibility is to create tests for each item on your work backlog. As items are completed, they should be immediately tested by your tester.
Now, in a modern agile environment this is usually done by your continuous integration environment. But normally, those environments don't do integration testing that well, which is where your tester comes in. AGain, remember, SCRUM teams are cross-functional, meaning they should include not only developers but also testers, CM, Requirements managers, etc. So, testing and defect tracking/correction will take place throughout your normal development sprints.
The testing sprint at the end of your development will be to validate the developed system works properly, prepare it for operational acceptance testing, deploy it into a operational test environment, excersize your system and then deployit into an operational environment.
3) Your Product Owner will be the one who determines that, and they will determine this by working with the customer as they prioritize thier product backlog. In reality, some business wonk will have signed the team up to deliver some sort of functionality by some fluid date range. The Product Owner will work with the customer to determine the degree to which that functionality should be implemented and exactly what should be included in each Sprint.
Of course, the Scrum Master and the development team will determine what they can actually develop during each Sprint and communicate this to the Product Owner. If the team provides feedback to the Product Owner that will result in a slip from the imposed time-line, it is the Product Owner's job to work with the customer to reprioritize the product backlog to take this into account.
Best Answer
You don't follow Scrum because your 3 PBIs are not PBIs. It is one PBI. Also if you divide the PBI this way and have special role for each part you are not doing Scrum but ScrumFall. Your cross functionality doesn't work at all because you have separate role for each task so while one role is doing its part of PBI other roles are waiting.
Cross functionality means that almost every member in the team can do any task and it is one of core requirements to make Scrum work. Otherwise you cannot efficiently plan the sprint because you must count velocity per role and combine PBIs in the way to fill capacity of each member - that is mostly impossible.