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!

[ac8318740]

Thanks so much for the review – really appreciate you getting to it so quickly. I've pushed an update that hopefully addresses everything you flagged:

• LexoRank ordering – switched from numeric midpoints to LexoRank strings, which handles the missing sort_order case properly now. Unranked neighbors get a rank assigned lazily via ensureRank() so subsequent drags stay consistent.
• Swimlane-aware reordering – computeSortOrder now threads swimlane params through so drags within a swimlane cell only consider tasks in that cell.
• Custom field mapping – threaded sortOrderField through all the internals instead of hardcoding sort_order. Should respect whatever's configured in settings now.
• Robustness – extracted a rankBetween() helper with try/catch around LexoRank.between() so equal-rank edge cases degrade gracefully instead of crashing. Also pinned the lexorank dep to exact version.

Also reworked the drop indicator UX while I was in there – replaced the thin accent line with an animated gap/slot pattern (cards shift apart to show where the drop will land), and fixed a couple of visual bugs with column resizing during drag.