Interactability `in view` definition seems ambiguous, making it unclear if `inert` elements are `in view`

While investigating a failure in the /inert/inert-pseudo-element-hittest.html test case on WebKit-based browsers, we determined that this occurs because WebKit doesn't consider an inert element to be in view because it has pointer-events: none. We are returning an element not interactable error code because of this. Other engines to not exhibit this behavior.

The spec says

An element is in view if it is a member of its own pointer-interactable paint tree, given the pretense that its pointer events are not disabled.

and

An element is said to have pointer events disabled if the resolved value of its "pointer-events" style property is "none".

@gsnedders and I are both unclear on what the intention of "given the pretense that its pointer events are not disabled" is. Should we be assuming that the pointer-events state is supposed to be ignored based on that, or does "given the pretense that" just mean "and".

Once we understand what the intention here is, we should clarify the spec itself to know if this is really just an "and" or if this is a "ignore this other thing".

Start with the /inert/inert-pseudo-element-hittest.html test case and the WebDriver definitions of “in view,” “pointer-interactable paint tree,” and “pointer events are not disabled.” Resolve whether the wording means to ignore pointer-events or combine that condition, then clarify the specification so the expected handling of inert elements is unambiguous.