fix: re-enable MacWebContentsOcclusion with embedder window fix (#50712)

fix: re-enable MacWebContentsOcclusion with embedder window fix (#50579)

* fix: re-enable MacWebContentsOcclusion with embedder window fix

Replace the full revert of Chromium's MacWebContentsOcclusion cleanup
with a targeted patch that handles embedder windows shown after
WebContentsViewCocoa attachment. This lets us drop the feature flag
disable in feature_list.cc and re-enable upstream occlusion tracking.

Adds tests for show/hide event counts on macOS and visibility tracking
across multiple child WebContentsViews.

* test: drop show/hide event count assertion

The assertion that 'show' fires exactly once per w.show() call is not
an API guarantee - macOS can send multiple occlusion state
notifications during a single show() when other windows are on screen
(common on CI after hundreds of prior tests). The
visibilitychange-count test in api-web-contents-view-spec.ts covers
the actual invariant we care about.

* fix: ignore WebContentsOcclusionCheckerMac synthetic notifications in window delegate

On macOS 13.3-25.x, Chromium's occlusion checker enables manual
frame-intersection detection and posts synthetic
NSWindowDidChangeOcclusionStateNotification tagged with its class name
in userInfo. These fire when the checker's NSContainsRect heuristic
decides a window is covered by another window's frame, but the real
-[NSWindow occlusionState] hasn't changed.

Our delegate was treating these the same as real macOS notifications
and emitting show/hide events based on occlusionState, which was
unchanged - resulting in spurious duplicate show events when e.g.
Quick Look opened and its frame intersected the BrowserWindow.

shell/browser/feature_list.cc

@@ -87,13 +87,6 @@ void InitializeFeatureList() {
       std::string(",") + sandbox::policy::features::kNetworkServiceSandbox.name;
 #endif
 
-#if BUILDFLAG(IS_MAC)
-  disable_features +=
-      // MacWebContentsOcclusion is causing some odd visibility
-      // issues with multiple web contents
-      std::string(",") + features::kMacWebContentsOcclusion.name;
-#endif
-
 #if BUILDFLAG(ENABLE_PDF_VIEWER)
   // Enable window.showSaveFilePicker api for saving pdf files.
   // Refs https://issues.chromium.org/issues/373852607

shell/browser/ui/cocoa/electron_ns_window_delegate.mm

@@ -43,6 +43,14 @@ using TitleBarStyle = electron::NativeWindowMac::TitleBarStyle;
 #pragma mark - NSWindowDelegate
 
 - (void)windowDidChangeOcclusionState:(NSNotification*)notification {
+  // Chromium's WebContentsOcclusionCheckerMac posts synthetic occlusion
+  // notifications tagged with its class name in userInfo. These reflect the
+  // checker's manual frame-intersection heuristic, not an actual macOS
+  // occlusion state change, so the real occlusionState hasn't changed and
+  // emitting show/hide in response would be spurious.
+  if (notification.userInfo[@"WebContentsOcclusionCheckerMac"] != nil)
+    return;
+
   // notification.object is the window that changed its state.
   // It's safe to use self.window instead if you don't assign one delegate to
   // many windows