single backlog requirements & incidents

Additionally, my PM/Managers want to know what bugs were found and/or resolved in the current sprint *and* how many bugs we are worried about. 

For example: The team agrees to pull in 10 bugs to resolve at the beginning of the sprint(iteration). During the sprint(iteration) we find 10 others, agree that 5 are severe enough to address this sprint(iteration) and the rest will go into our backlog. There are now 15 total bugs that we will fix this sprint and 5 we will leave for future sprints.

I cannot figure the *single* place to find this information in Spira. At this time I know the Main Project Page --> Incident Summary will show the incidents found during the iteration when filtered properly and the Reporting --> Incident date range graph will show what we have fixed/found during the iteration (when filtered correctly) but neither address showing what we are starting the sprint with. 

WE've tried the "Create a requirement from this incident" but this creates it's own issue as the requirement is not updated as the incident moves through the workflow which requires the developer to update multiple fields when resolving issues. 

Is there a simpler way for the PM/Manager to get the data or is the developer right and he has to spend 4 days to build a tool to get the custom data by tagging the db through the API?

I have also fought with this issue, and have had to work around the tools limitations. My general approach is to make sure everything is a requirement, as that appears to be the sole view that can give me insight as needed; Planning -> Requirements. With regards to defects, the only way is to generate a requirement form the incident and then we preface those with DEFECT: so that we can identify them in the aforementioned view. As you noted, changes to the requirement are not captured in the incident but there is an association created when you create the requirement form the defect. I have hard that the next release is supposed to mitigate some of these non-Agile approaches that have been forced in to the workflow of the tool.