As for tracking usage of NOSONAR, I believe you’ll be interested in this rule. In addition, SONARJAVA-2749 is scheduled for the next release of SonarJava and will implement a rule that tracks cases where NOSONAR is used but not actually suppressing an issue.
generally speaking usage of //NOSONAR is not a recommendation nor a common practice (risk of having to maintain in-source exclusions, and forget context too). You’re better off letting SonarQube catch the issue, and then you can declare it ‘Won’t Fix’ from there on (providing a justification comment). SonarQube will then fully track that issue state across refactorings, file move etc. and you keep the big picture at all times