Problem

On Android Chrome/Edge (and likely other touch browsers), tapping Edit/Delete/toggle controls inside jQuery UI sortable items often fails or needs many retries. Confirmed on Project Settings → Workspace Spec: the whole .card-header is the sortable handle (ui-sortable-handle), and action controls are <a> elements inside it.

Reported / diagnosed in #2897.

Example markup (from reporter):

<div class="card-header ui-sortable-handle">
  <div class="card-title">
    <a class="toggle">...</a>
    <span class="drag-indicator">…grip…</span>
    <span class="mr-3">…title…</span>
    <a class="btn …" data-tippy-content="Edit this spec">…</a>
    <a class="btn …" data-tippy-content="Delete this spec">…</a>
  </div>
</div>

Code touchpoint for this page:

• WorkspaceSpecsPage.java: new SortBehavior() { … }.items("li.spec").handle(".card-header")
• Markup: WorkspaceSpecPanel.html (edit/delete/toggle links live in the header)

Same pattern exists elsewhere (e.g. workspace provisioners, other card/table sortables where the handle overlaps action links, or whole rows are sortable with no dedicated grip).

Root cause

1. jQuery UI default cancel is input,textarea,button,select,option — links (a) are not cancelled, so drag can start on edit/delete links.
2. SortBehavior supports handle / items / distance but has no cancel API; many call sites use a broad handle (or none).
3. Touch Punch skips synthesizing click once any touchmove occurs — common on Android even for careful taps.

Suggested fix

Prefer both (order of preference):

1. Narrow drag handle to the grip (e.g. .drag-indicator) so Edit/Delete/toggle are outside the handle.
2. Extend SortBehavior to pass jQuery UI cancel, with a sensible default including a, button, …, .no-drag, so taps on interactive controls never start sortable/drag while the rest of the row/card remains draggable.

Optional: slightly increase distance on touch-heavy UIs.

Acceptance criteria

On Android Chrome/Edge:

1. Single careful tap opens edit/delete/toggle every time on workspace-spec cards (and similar UIs).
2. Reorder still works from the intended surface (grip / non-link area).
3. Spot-check other SortBehavior sites that put actions inside handles or whole-row sortables (settings tables, build-spec lists, board-related sortables as applicable).