Unfortunately, I don't think this approach is going to work out for what you're trying to accomplish.
AVHardwareDisable is intended for system administrators who want to disable camera/microphone access entirely in sensitie environments where eavesdropping is a concern.
AVHardwareEnabledDomain only works when AVHardwareDisable is set to true, and is a mechanism for explicitly whitelisting one or more domains for which camera/microphone access should be allowed, like the company's conferencing software.
As far as we can tell, the original intent is not to suppress the user dialog. We would not, as an example, want to enable employers to watch employees via their webcam without getting their consent. We *would* want them to be able to block malicious ads from prompting their users for camera/mic access, while still allowing them access to the company's conferencing services.
More importantly, when we talk about browsers with modern plug-in sandboxes, like Google Chrome or Edge, the browser intercepts requests for camera and microphone and presents a native permission dialog, which doesn't know about mms.cfg settings. Moving permissions to native dialogs ensures that we behave consistently with HTML5/WebRTC features, and largely solves the clickjacking problem (it's easier to track what's actually visible to the end-user from the perspective of the browser vs. the view from an element in a browser page).
As a long-term strategy, I don't see this being viable across the major browsers. This really seems like a job for a native application.