Fix: mark tasks as scheduled when rescheduling during overdue review

[badrbouslikhin]

Summary

• When scheduling a task to a future date during overdue task review, handleArrowDatesAction() updated the content with the >date suffix but never changed the paragraph type from open to scheduled
• This caused tasks to still appear as active ([ ]) instead of rescheduled ([>])
• Added type changes matching the pattern already used in scheduleItem() in helpers/NPScheduleItems.js

Test plan

• Start a review of overdue tasks
• Schedule a task to a future date
• Verify the task checkbox changes from [ ] to [>]

Fixes #741

[dwertheimer]

Thanks for this @badrbouslikhin — you found a real bug, and the diagnosis is right: handleArrowDatesAction() was updating the content but never the type. I pushed a follow-up commit to your branch rather than asking you to iterate, because the fix turned out to need more than the type change. Explanation below so the reasoning is on the record.

Why the type change alone would have made things worse

In NotePlan, [>] (scheduled / checklistScheduled) does not mean "this has a future date on it" — it means "this item is handled elsewhere". A [>] line is deliberately excluded from the target date's references.

So with the original patch, rescheduling an overdue task to next Tuesday would have marked it [>] and left it sitting in the old note, and it would not have shown up on Tuesday. The checkbox would look right and the task would silently vanish from the review cycle — worse than the bug being fixed.

The [>] marker is only half of NotePlan's scheduling operation. The other half is a copy in the destination note that back-links to the original:

# in the original calendar note
* [>] pay invoice >2026-08-05

# added to 2026-08-05
* [ ] pay invoice <2026-07-28

The two always happen together. That is why scheduleItem() in helpers/NPScheduleItems.js — which you correctly identified as the reference implementation — does the destNote insert right after the type change.

What the follow-up commit does

handleArrowDatesAction() now delegates to those existing helpers instead of hand-rolling the logic, mirroring jgclark.Dashboard::doRescheduleItem() so the two plugins behave the same way:

• Regular (non-calendar) notes → scheduleItemLiteMethod(): rewrite the >date in place, leave the type alone. scheduleItem() explicitly declines to run on regular notes, and this also matches NotePlan's own "Schedule by linking in regular notes" preference.
• Calendar notes → scheduleItem(): mark the original [>] and add the back-linked copy to the destination calendar note.
• CMD-modifier path unchanged: that is a move, not a reschedule, so it still strips the date and hands off to processCmdKey().

Three settings come along, mirroring the Dashboard plugin: useLiteScheduleMethod (opt back into pure in-place rescheduling), newTaskSectionHeading and newTaskSectionHeadingLevel (where the copy lands).

Tests

The existing handleArrowDatesAction test was passing a bare { content } object with no note, which the helpers require, so I gave it a real mock note and added cases for both methods and for the task/checklist variants. 14/14 in that file, full suite green (the one np.Templating failure is a live web-API test timing out, unrelated). Also added the missing DataStore.updateCache to the shared mock.

One thing worth a second opinion

The default is useLiteScheduleMethod: false, matching Dashboard — so calendar-note tasks now get the full copy method. That is what actually fixes #741, but it does change the default behaviour of the overdue review, which was previously pure in-place. If we would rather ship this opt-in, flipping the default to true is a one-line change.

[badrbouslikhin]

Thanks for the feedback and the fix!