### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Electron Version

16.0.0

### What operating system are you using?

macOS

### Operating System Version

macOS Monterey 12.0.1

### What arch are you using?

x64

### Last Known Working Electron version

n/a

### Expected Behavior

Window does not have a white background when vibrancy is set to under-window + transparent background is used on macOS

### Actual Behavior

Window with vibrancy and transparency enabled is rendered with a white background, at random

### Testcase Gist URL

_No response_

### Additional Information

We're still hitting random issues with Electron where creating a window with vibrancy + transparent body will result in a white background. I was hopeful that the 16.0.0 release would have fixed this as it was mentioned in the changelog, but seems like the issue persists.

I've tried to narrow down to a reproducible case, but didn't manage to do so - I've observed all these variations across executions:

- Window opens with correct vibrancy effect, and it works without issues
- Windows opens with correct vibrancy effect then goes white after ~4 seconds - consistently after ~4 seconds
- Window opens with correct vibrancy, stays without issues, but loses after some time of switching between apps
- Windows open with effect already not working and a white background

I've already tried all suggestions from previous issues like #30993 or #31461 . The window is created with vibrancy set to under-window, has a transparent background and the webpreferences also has a transparent background set. As it works sometimes, I assume the options here are correct.

My guess is that this is somehow related to #31019: Electron is using somehow the background color of the HTML body. As we initially load the window with about:empty, then navigate to our url, the transparent background logic might be loading the incorrect background color at random times and breaking the transparency/vibrancy effect from there on. 

I also don't know if #31722 is already merged on the 16.0.0 release - happy to test if not the case once it is again!

shell/browser/api/electron_api_web_contents.cc
auto* ontents = GetWebContents();
  if (!ontents)
    return;
  if (active) {
    eye_dropper_ = std::make_unique<DevToolsEyeDropper>(
        ontents, base::BindRepeating(&WebContents::ColorPickedInEyeDropper,
                                          base::Unretained(this)));
  } else {
    eye_dropper_.reset();
  }
}
void WebContents::ColorPickedInEyeDropper(int r, int g, int b, int a) {
  base::DictionaryValue color;
  color.SetInteger("r", r);
  color.SetInteger("g", g);
  color.SetInteger("b", b);
  color.SetInteger("a", a);
  inspectable_ontents_->CallClientFunction(
      "DevToolsAPI.eyeDropperPickedColor", &color, nullptr, nullptr);
}
#if defined(TOOLKIT_VIEWS) && !defined(OS_MAC)
ui::ImageModel WebContents::GetDevToolsWindowIcon() {
  return owner_window() ? owner_window()->GetWindowAppIcon() : ui::ImageModel{};
}
#endif
#if defined(OS_LINUX)
void WebContents::GetDevToolsWindowWMClass(std::string* name,