Application Dictionary add-on may not cover domain-based configuration profiles, something that was requested on GitHub a while ago (in a slightly different wording).
For those unaware: when reviewing pull requests (code differences or diffs) on GitHub, code changes are laid out in a table. There is a button for each line where reviewers can add comments to specific lines (I usually don't use this method, rather I comment on sections (multiple lines) and give overall comments on a pull request).
Using a speech dictionary (perhaps a regular expression) may provide some help in this case, but there are downsides, namely NVDA trying to process "button" text on different websites and not giving you what you want to hear. I personally think it is an issue with GitHub itself, so perhaps suggesting a change to Microsoft (the owner of GitHub these days) would be better. Personally, I don't review pull requests via GitHub interface - I use Git (WSL2 version) directly as it does provide unified diffs of changes (a unified diff is a change where each line is proceeded by a plus (+) or minus (-) to indicate code changes); I also review commit logs to better understand the context around code fragments (I have some opinions about Git commit logs, particularly for add-ons, but won't discuss it here).
Although the issue presented deals with a single website and how controls within it are presented and announced, it can be argued that it should be applicable when using other web browsers when accessing GitHub. I'm skeptical of this, seeing that what really presents web content is not just the web browser, but the rendering engine chosen and website code that can do things with the site interface such as adding, changing, and removing things (there is a somewhat related discussion on WinAccess forum about website ads). What may work with Chromium-based browsers such as Chrome and Edge may not work with Firefox as they use different rendering engines to present web content, and folks were having debates about how different content should be presented to screen readers in a more unified way (not to mention workarounds that involve not only the web content, but the accessiblity API's such as IAccessible2 and other layers, something that will take several days to explain).
My advice: take both the short-term and long-term approach regarding this issue.