[popover]: event propagation for the escape key

Right now, elements with popover dismiss with the Escape key out of the box, but do not prevent that keyboard event from reaching the DOM, and propagating up through its ancestors. Functionally, that means that popovers nested within other controls like dialogs, sidepanes, etc. would in most cases also cause those wrapping controls to close when the popover is escape-dismissed.

This is different from the established behavior of browser escape handling in existing HTML elements with popups (select, color inputs, and date inputs), where using Escape to close them does not generate a keyboard event in the DOM. That's more a side effect of those being fully browser-rendered UI, but the end result is still the same -- they can be safely closed without causing wrapping controls to also close.

While interestingly it doesn't look like the native <dialog> element closes as a result of an inner popover escape-dismissing, any higher-level custom keyboard listener that handles escape would catch it and dismiss the dialog, e.g.: https://jsfiddle.net/Lrkce325/

Most open source control libraries rely on downstream controls stopping propagation to handle multiple levels of popups. Since popover doesn't currently do this, I'm not sure if it's possible to safely use it together with any library's custom dialog component. Referring to the Open UI Dialog page, all the libraries linked in that page with live examples that I was able to test showed this exact issue.

The popover attribute is rather different from select, input type=date, and input type=color, so fully obscuring the event seems wrong here (even more so because popover could itself have nested controls that need to handle escape). My first thought was to allow the capture phase but stop propagation past the popover node (or past the trigger, if focus is there), but that's only an initial idea, I'm sure there are potential issues with that approach as well. I'm curious if other folks also see this as an important issue, and other thoughts on how to solve it.

Start by reviewing the linked Open UI Dialog research page and the jsfiddle reproduction, then compare the described Escape behavior across popover, dialog, and other browser popups. Done would require an agreed behavior and corresponding Open UI specification update, but the issue does not identify a file or test to change.