Taskbar Auto-Hide Hover Trigger Buried by Maximized Windows (DWM Z-Order Bug - Build 26220)

I am reporting a persistent and reproducible bug where the Taskbar auto-hide "trigger zone" is physically obstructed by maximized windows. This issue started after a recent Windows Insider update and has survived a Tier-1 Microsoft Remote Support session.

The Symptoms:

Auto-hide fails ~90% of the time when any app is maximized. Hovering at the bottom of the screen does nothing.

Auto-hide works perfectly when windows are windowed (not maximized).

Explorer Reset Inconsistent: Unlike standard UI glitches, restarting explorer.exe via PowerShell seldomly fixes the issue. Even after a shell restart, the taskbar often remains "buried" behind the maximized window.

Intermittent behavior: The feature occasionally functions correctly for brief periods before failing again without a clear trigger.

The "Rescue" works: Pressing the Windows Key brings the taskbar up instantly, confirming the process is active—only the mouse-hover detection is blocked by the window layer.

Hardware & OS Context:

OS Build: Win 11 Pro - Build 26220.8138 (25H2)

Display: Alienware QD-OLED 34" (AW3423DW) @ 3440x1440p (Issue persists across all refresh rates from 60Hz to 175Hz).

Mouse: Logitech MX Master 3S (Issue persists even when all logioptionsplus processes are killed).

Troubleshooting Already Exhausted:

Microsoft Remote Support: A technician remoted in and was unable to resolve the issue using standard UI toggles.

Cleared StuckRects3 registry cache.

Toggled all "Taskbar Behavior" settings, Transparency effects, and Overlays (NVIDIA/Discord/Steam).

Performed full SFC /scannow and DISM /RestoreHealth.

Feedback Hub Link: 

https://aka.ms/AA10exq5

I have officially submitted this via the Feedback Hub with telemetry logs here: aka.ms

This appears to be a core shell conflict where maximized windows are incorrectly claiming "Exclusive Fullscreen" priority, masking the 1-pixel hover boundary. Given that even an Explorer restart fails to consistently restore the trigger, is this a known regression in the Desktop Window Manager (DWM) for build 26220?