The issue here is that gestures on the edges of phones withhold touch information until the touch is released. This detects a "touch press (TouchPhase::Began" and "touch release (TouchPhase::Ended) " in the same frame.

In Input Legacy we did delay the TouchPhase::Ended to the next delay but we purposely don't do that by default with the Input System. Here's the reasoning from our code comments (see https://github.com/Unity-Technologies/InputSystem/blob/4e8347ae838f01b283d331a2e2a3b841d58e72cc/Packages/com.unity.inputsystem/InputSystem/Devices/Touchscreen.cs#L599-L610)

NOTE: We do NOT make a effort here to prevent us from losing short-lived touches. This is different
from the old input system where individual touches were not reused until the next frame. This meant
that additional touches potentially had to be allocated in order to accommodate new touches coming
in from the system.

The rationale for NOT doing this is that:

a) Actions don't need it. They observe every single state change and thus will not lose data
even if it is short-lived (i.e. changes more than once in the same update).
b) The higher-level Touch (EnhancedTouchSupport) API is provided to
not only handle this scenario but also give a generally more flexible and useful touch API
than writing code directly against Touchscreen.

The alternative is to use the EnhancedTouch API provided with the Input System (see https://docs.unity3d.com/Packages/com.unity.inputsystem@1.11/manual/Touch.html#enhancedtouchtouch-class)
In this case, if a short-lived tap is done within a frame, this API "records the history" of all touch state changes and will in fact delay the Ended phase into the next frame.