SonarQube only shows issues in pull requests that have locations involving lines of code that were changed in that P/R.
This strategy filters out a lot of issues that are not relevant to the P/Rs, and brings the focus to the code that was changed in the P/R.
However, it's possible to have issues that were already present before those changes. In other words, there is no guaranteed causality between a change in a line and an issue located in that line, resulting in false positives in pull requests.
If an issue already existed in the source branch of the pull request, and it was resolved (for example, marked as "won't fix"), we should carry that resolution to the matching issue in the pull request.
We do "issue tracking" with the pull request itself, to keep changes done by the user to issues in the pull requests. We should also do "issue tracking" with the source branch (if it exists in SonarQube).
This issue tracking should be done only when the issues are first seen in a P/R, so that it doesn't override changes done by users to issues in the P/R.