I don't quite get the problem this tries to solve.
I'm not quite sure that the bug list is the integral part of the source code. And there are dedicated systems that work just fine.
And if I really feel like tagging bug tracker along with my code, I could use any of those systems as long as they support file based databases, like sqlite, or simply static text files for that matter.
The resolved bug list in particular is an integral part of the source code history, because it explains the motivation behind the shape of that code.
From my own experience, debugging often means digging into git blame and finding the issues associated with those commits. Having that metadata directly in a repo, not tied to any specific platform, always in sync, is nice.
There is a certain appeal to not depending on more tools, and there is something elegant about the bug list traveling with revisions, if they are closed when the bug is fixed. So at any point you could go backwards and see known bugs at the time.
This also applies to certain project management flows and statuses.
Right, there are advantages of your defect list riding right along with the code repository itself. The history here is more interesting and keeping it connected to git allows portability options (maybe across network divides).