Hold a press for the length of a touch, and fix the click sequence counter

[sapkra]

⚠️ Base this on fix/tap-slop-click-detection, not main. It builds on that branch's tap-slop work — the safe moment to emit an early press only exists because of it. If that PR merges first, retarget to main.

Three follow-ups to the tap-slop PR, all in the click bookkeeping. Stacked on top of it —
please review that one first.

Relationship to #23 (please read before merging either)

#23 independently found and fixed one of these bugs, and the two changes collide. Worth
settling merge order first.

Overlap. The Euclidean double-click fix (hypot instead of comparing two signed axis
deltas with &&) is in both. @Jac0b-Shi got there independently — same diagnosis, same fix.
It sits in this PR's base branch rather than here, so one of the two should drop it,
whichever lands second.

Conflicts. A test merge against #23 conflicts in four files:

Touch Up/SettingsView.swift
Touch Up/TouchUp.swift
TouchUpCore/TUCCursorUtilities.m
TouchUpCore/TUCTouchInputManager.m

The same four conflict from the base branch alone, so this is one overlap across the whole
stack rather than something introduced here. This PR deepens it: #23 adds logCursorEvents
logging inside performClickAt:, which this PR rewrites, and both edit
updateCursorClickCountWithLocation: and the tail of processTouchesForCursorInput.

Not just textual. #23 adds cursorTouchInitialLocation + tapMovementTolerance —
origin-based tap slop, the same mechanism as the base branch — but gated behind
usesWindowsTouchMode:

if (!self.usesWindowsTouchMode || exceededTapMovementTolerance) {
    self.cursorTouchQualifiedForTap = NO;
    self.cursorTouchStationarySinceDate = nil;
}

With the mode off (the default) !usesWindowsTouchMode is true and the flag is cleared on any
non-stationary report, exactly as before — so #23 leaves #13 unfixed for anyone who doesn't
opt into a mode that also changes first-tap-moves/second-tap-clicks, long-press → right-click,
and one-finger-drag → drag. Once tap slop exists unconditionally, that machinery is largely
redundant and Windows Touch Mode can be built on tapTolerance instead of carrying its own.
Whoever merges second should reconcile rather than resolve markers.

One more thing worth folding in from #23 either way: its
distanceInMillimetersBetweenRelativePoint:and:locationID: reads nativePhysicalSize
unguarded, so on a panel reporting no EDID size it returns 0 and the tolerance becomes
effectively infinite. The base branch's effectivePhysicalSize covers that.

Press and hold

A tap emits its mouse-down and mouse-up together at lift-off, so no app ever observes the
button being held. This came up in #13, where it was floated as a possible cause:

mouseUp and mouseDown both instantaneously fire upon releasing a touch, rather than
mouseDown firing the moment a touch is detected

That's an accurate description, and it isn't the cause of #13 — but it is a real limitation,
and the reason behind it is worth stating because it constrains any fix. While the finger is
on the glass the gesture is genuinely undecided: tap, scroll, pinch and secondary click all
begin identically. A delivered press cannot be withdrawn, so pressing at touch-down would
start a text selection every single time the user meant to scroll. There is no eager press
that is safe in general.

There is a safe moment, and the tap-slop work created it: by the time a hold is recognised,
a scroll or a pinch would already have moved. So TUCCursorGestureLongPress — defined in the
enum since the beginning and never once posted — is now emitted there, exactly once per
touch. Mapping it to a drag presses the button at that point and holds it until lift-off,
which is what apps reacting to a held button need. The lift-off click is then suppressed,
keyed off the button already being down, so a touch still actuates exactly once.

Exposed as "Press and Hold" in Settings → Gestures, off by default. It converts a
long rest into a held button rather than the click it produces today, and that should be a
deliberate choice rather than something users discover by accident. With it off the gesture
maps to .none and nothing about current behaviour changes.

Releasing the button on digitizer disconnect goes with it. Stale touches are only reaped as
further reports arrive, so a device unplugged mid-touch left the button down forever. That
was already reachable during a drag; it becomes more reachable once any resting finger can
hold the button, so didDisconnectTouchscreenWithLocationID: now stops the gesture.

Click sequence counter

Two defects, both making the sequence advance where it should have restarted.

The count wrapped from 4 back to 1. So the fifth press of a rapid series looked like the
second press of a new double click, and repeated tapping produced double clicks nobody asked
for. A real mouse keeps counting past three — a quadruple click selects a paragraph in some
text views — so the cap is simply gone rather than moved.

Only performClickAt: moved the reference time and location forward. The press that
starts a drag advanced the count without moving them, so the window for the next tap was
still measured from the click before the drag, letting that tap inherit a count it had not
earned — tap, drag, tap in one spot arrived as a triple click. The update now lives in
updateCursorClickCountWithLocation:, next to the decision it serves, so every emitted press
becomes the reference for the next one.

That second fix turned out to be a prerequisite rather than a nicety: press-and-hold never
calls performClickAt:, so without it the reference would never advance and a double tap
could never form at all.

The raise-click was a click too

With Bring Windows to Front enabled, a tap on a window that isn't frontmost produced
two full clicks: TUCCursorActionMoveClickIfNeeded injected one to raise the window, and
the same tap's lift-off produced the real one. Both went through performClickAt:, so the
injected click advanced the sequence and the real one landed at the same spot, inside the
double-click interval, as click state 2. Every tap on a background window was a double
click — in Finder, that opens the item the user meant to select.

It leaked the other way as well: because the raise reused the user's live click count, a tap
shortly after a double tap raised the window with click state 2 or 3.

bringWindowToFrontAt: already existed for precisely this job — click state pinned to 1, the
click sequence left alone — and had never been called from anywhere. Wiring it up is the
entire fix.

The title-bar strip in isLocationOutsideFrontmostWindow exists only as a workaround for this
bug (its comment says so), and in principle becomes redundant. I've left it in with a comment
recording that, rather than deleting it: the case it guards is a window zooming to fullscreen,
which is destructive enough that it deserves a real-hardware check before the guard goes.
Removing it would restore raise-on-tap for background title bars.

Also

performClickAt: built its event pair by re-typing and re-posting a single event object,
which gave the press and the release one shared creation timestamp and therefore a press
duration of exactly zero. It now creates both events. I can't attribute a specific app
failure to this, so treat it as making the injected click well-formed rather than as a fix
for anything observed.

Compatibility

Configuration	Behavior
Press and Hold off (default)	LongPress maps to .none; unchanged in every respect
Press and Hold on, tap shorter than Hold Duration	One click on lift, as before
Press and Hold on, tap longer than Hold Duration	Button down at recognition, up on lift — one actuation, no extra click
Press and Hold on, rest then drag	Same drag as today, just pressed earlier
Press and Hold on, double tap	Click states 1 then 2 — works because of the reference fix above
Bring Windows to Front on, tap on background window	Window raises, then one single click (was: double click)
Bring Windows to Front on, genuine double tap	Second tap needs no raise, so it still doubles correctly
Bring Windows to Front off (default)	Untouched — the raise path never runs
Device unplugged mid-touch	Button released instead of stuck down (improvement, applies either way)
Touch cancelled / stale	Already released via stopCurrentGesture; unchanged

Word-selection drag (a drag inheriting click state 2 right after a tap) still works — that
behavior is the reason dragCursorTo: advances the counter at all, and it's preserved
deliberately.

Testing

Builds clean, no new warnings. No touchscreen here, so all of the above is traced through
the code rather than measured. Two things want real-device confirmation: Press and Hold,
which is why it ships off by default, and whether the title-bar strip can now be deleted.

[Jac0b-Shi]

Thanks for the very thorough write-up. I agree that this is more than a textual conflict, and that the shared tap-slop and click bookkeeping should probably be established first rather than duplicated across the two implementations.

The overlap around the Euclidean double-click check is straightforward, and I am happy to drop or rework that part of #23 depending on the eventual merge order. The same applies to the origin-based tap tolerance: having one unconditional tapTolerance implementation underneath both the default behavior and Windows Touch Mode is cleaner than maintaining two similar mechanisms.

My current preference would be to land #28 first, then #29 on top of it, and finally rebase #23 onto the resulting code. I can then keep the parts that are still distinct in #23—per-digitizer calibration, HID/event logging, device identity, and the Windows-style gesture mappings—while adapting them to the shared tap-slop and click-sequence implementation.

The long-press behavior will need an explicit reconciliation rather than a mechanical conflict resolution, since #23 currently maps it to secondary click in Windows Touch Mode while this PR introduces an optional held left-button action. I think those behaviors can coexist with a clear precedence or mutually exclusive setting.

The fixes here for click-sequence anchoring and the window-raising click also make sense to me. I can help test the press-and-hold path, background-window clicks, title-bar behavior, and the interaction with Windows Touch Mode on real touchscreen hardware once the branches are in a testable order.

Thanks again for tracing the overlap in detail and calling out the relevant parts of #23.