I just wanted to expand on my comments on the question, as an answer.
Of the three types of defects that you identified in the question, I only see two types of defects. The first one, bugs introduced by current stories, is an in-phase defect. The other two are out-of-phase defects.
The concepts of "in-phase" and "out-of-phase" come from the measurement of defect detection efficiency or defect removal efficiency. In a sequential model, a "phase" is an activity of development - requirements, design, coding, etc. In an agile methodology, I'd consider a "phase" to be an iteration. If you do not release at the end of every iteration, you may consider a "phase" to be a release, as well, but I think that it is easier to track each iteration as a phase.
If you detect an issue before a story is marked as Done (as defined by your Definition of Done), you can create a subtask on the ticket. In the instance of JIRA that I use, a Story can have different types of subtasks, one of which is a Story Bug. A Story Bug would indicate that an issue was found in code review, independent QA, or acceptance testing that needs to be resolved while a Task subtask would simply be something to do.
Once a story is marked as Done, if there is an issue with it before the release (perhaps because of a conflict with another story or change made), it can be reopened and an appropriate subtask added. However, any issues found related to a story or task that has already been released are put in as a Bug, which is a top level task type in JIRA. It's also linked back to the appropriate story for record purposes, but the original story remains in a Released state.
If you also add a field in JIRA to track the Sprint where you suspect the issue was injected, you can do some more fine-grained tracking about the age of the issue. This may help in prioritizing. However, it may not be entirely accurate - you may not always know for sure when a defect was actually injected into the software, but you can guess based on file change history.
When reporting, there's no reason to differentiate between what you are considering type two (bugs discovered but are not from current stories) and type three (bugs from previous work that are moved into current sprint to be fixed) bugs. If, in the course of doing work on an iteration, you find a bug that has yet to be reported and exists in released code, simply enter it as a bug and have it go through your triage process. If it's severe enough, you can adjust your iteration scope. If it's not, you can prioritize it for the next iteration.