The "Firefox DevTools ADB Extension" is a privileged extension (in the sense that it is signed as a Mozilla Internal Extension) and, as a privileged extension, it gets the permission to access PB windows by default on its startup, and that is very likely the reason why setting "Don't Allow" on it is quickly reverted to "Allow".
Unlike other system addons it is not built-in (but installed when the DevTools internals are going to need it to reach a remote android target) and it is not marked as hidden in the manifest.json.
This extension is actually used only to provides the ADB binaries, it doesn't contain any extension page or experiment APIs, and so the option to "Allow/Don't Allow PB windows access" wouldn't really do anything useful on this extension, and so allowing it doesn't seems to make a lot of sense for this extension.
The following are a couple of strategies that we may use to avoid this unexpected behavior:
hiding the "Allow/Don't Allow PB windows access" radio buttons for any privileged extension signed with the Mozilla internal key (but this may be too much, in some cases it may be reasonable to allow the user to toggle this permission on an extension signed with the Mozilla internal key)
or adding support for an additional manifest key, only available to Mozilla Internal Extensions (similarly to the
hidden manifest property), that would allow an internal extension to ask Firefox to hide the "Allow/Don't Allow PB windows access" radio buttons and the "incognito badge", to be used for internal extensions that are not hidden in about:addons when we know that toggling the "PB windows access" doesn't make any sense (as in this case) or when "denying the PB windows access" would completely break the internal extension