feat: add drag-to-reorder for kanban and task-list views

[ac8318740]

Summary

Adds drag-to-reorder for both kanban and task-list views using a sort_order frontmatter property.

The point of this is to let you prioritize tasks within a priority group, e.g. ordering your three "high" priority tasks in the sequence you actually want to do them. This is groundwork for auto-scheduling: once tasks have a stable intra-group ordering, a scheduler can slot them into time blocks without the user having to re-specify intent.

What's included

• Kanban view: card-level drag-and-drop reordering within columns, midpoint insertion algorithm, collision handling (renumbers when neighbours share identical values)
• Task-list view: drag-to-reorder within groups, plus cross-group dragging (updates both sort_order and the group property)
• Shared sortOrderUtils.ts: extracted free functions (computeSortOrder, getGroupTasks, renumberAndInsert, etc.) so both views use the same algorithm
• FieldMapper / types: sortOrder field in TaskInfo, default field mapping, read/write support
• CSS: drop indicator pseudo-elements for visual feedback, simplified drag styling to fix hit-test issues
• Configurable property name: the frontmatter property used for sort order is configurable via Settings > Task Properties > Metadata Properties > Sort Order (defaults to sort_order)

Configurable sort order property

The sort order property name is wired through the existing FieldMapping system, the same system used by every other property (status, priority, due, etc.). This means:

• Default behaviour is unchanged - the default mapping is sort_order, so existing users are unaffected
• Users can customise it in Settings > Task Properties, in the Metadata Properties section, via a "Sort Order" property card

Design notes

• Midpoint insertion: new_value = floor((above + below) / 2) gives O(1) placement without rewriting the whole list
• Vault-wide neighbour lookup so filtered/hidden tasks are still considered (prevents collisions)
• Container-level drag event delegation so it works with both normal and virtual-scrolling rendering
• Deferred re-render during drag to prevent DOM destruction mid-drop

Test plan

• Existing unit tests pass (FieldMapper, bases)
• Drag a card within a kanban column, verify order persists after reload
• Drag a card in a grouped task-list, verify it stays in position
• Drag a card between groups in task-list, verify the group property updates
• Rapidly reorder many cards to trigger collision renumbering, verify no duplicate sort_order values
• Change the sort order field mapping in settings to a custom name, confirm drag-to-reorder reads/writes the custom property
• Confirm drag-to-reorder only activates when the view is sorted by the configured property name

[callumalpass]

Thanks so much for pushing this, @ac8318740 ! I’ve been interested drag-to-reorder in TaskNotes for a long time (see issues #186 , #219 , #621, #701) and hadn’t been brave enough to tackle it myself. This gets close and the direction is strong.

After testing in my vault, I’m seeing a few blocking robustness issues:

• When most notes don’t already have sort_order, reordering is pretty buggy and can land notes in unexpected places.
• Kanban drag/reorder in swimlane mode is unreliable
• There are still paths where writes look hardcoded to sort_order, which breaks custom mappings.

My suggestion for the next iteration: switch the ordering model to LexoRank (string ranks) and make DnD placement strictly swimlane-aware when swimlanes are enabled. This will require a lot of manual testing. I’d prioritize robustness over minimal complexity here, because this feature will get heavy use once merged.

Thank you for doing the hard part of getting this moving!