fix: bind a drag when its contact begins, not on the tap edge

[winst0niuss]

The problem

On a touch board, dragging a slider only works if the finger pauses before it starts moving. A drag that begins immediately — the natural gesture — does nothing at all: the handle stays put, and nothing happens on release either. Try again, dwell for a moment first, and it drags normally.

Reported against CrossPoint's frontlight panel (brightness and warmth sliders), but nothing there is specific to that screen — it is the shared routing.

Root cause

InteractionTable::routeAgainst() binds a drag to its element only on the press edge:

if (input.touchPressed) {
  active_ = findTouch(slot, input.touchX, input.touchY, InputTouch);
}
if (input.touchHeld && active_ >= 0 && ...) {   // needs active_
  dragged.dragPermille = dragPermilleFor(held.rect, input.touchX);
}

If active_ is never set, every held frame is dropped silently.

Consumers derive touchPressed from a contact that has already read as a tap. In CrossPoint that is MappedInputManager::wasScreenTouchDown(): it needs InputManager::isTouchTapCandidate() — false once the contact passes the 28 px TOUCH_TAP_SLOP_PX — and a hold of at least 90 ms. A finger that starts moving as it lands fails both halves, so the press edge never arrives and the drag is never bound. On release, wasTouchTap() fails too (slop exceeded), so the snapshot carries no coordinates and even the tap-to-position path is skipped.

The fix

Bind on the frame the contact begins as well, hit-testing where it landed rather than where it has since travelled to.

The landing point matters: binding against the live position would let a contact that started somewhere else grab a slider just by passing over it, which is a worse bug than the one being fixed. contactHeld_ mirrors the previous routed frame's contact so the opening frame is recognisable, and nothing rebinds until the contact ends.

findDrag() requires the InputDrag bit strictly, unlike findTouch(), which also matches anything accepting InputTouch. Buttons, tiles and list rows are therefore never bound and keep their press-then-release semantics unchanged.

One case this does not cover: a screen appearing while a contact is already down would see its first held frame mid-gesture. It does not arise today — swipes are recognised on release (InputManager::wasSwipe() requires touchReleasedEvent), so a gesture-opened screen never inherits a live contact. Carrying the real down point in InputSnapshot would close it off for good, at the cost of a snapshot field every consumer has to fill.

Exercised in the desktop simulator on an X4 Pro profile, not yet on physical hardware — contact timing there differs, so a check on a real device would be worth having before merge.

[itsthisjustin]

Yep I noticed this too. Ready to merge on this?

[winst0niuss]

Yes, it's ready