Add completionDate + completedAfter filter to list_tasks; fix containerId on completed tasks

[vishae]

Summary

• list_tasks didn't expose a completed task's completionDate — only get_task did, one task at a time, so finding "everything completed since X" required fetching every completed task individually. Added completionDate to list_tasks' output (null for incomplete tasks, consistent with dueDate/deferDate/plannedDate) and a new optional completedAfter (ISO datetime) filter, following the existing dueBeforeDate pattern.
• list_tasks and get_task both resolved a task's containerId/containerType via assignedContainer, which comes back null for completed tasks. The write-path snippets (move_task, complete_task, create_task, edit_task, drop_task) already avoid this — move_task.js has a comment noting assignedContainer "reflects original placement and doesn't update after moveTasks." Applied the same parentTask/containingProject fallback to list_tasks and get_task so completed tasks resolve their container correctly too.
• package-lock.json also resyncs to package.json's current name/version (it had drifted to omnifocus-mcp@0.1.0 vs. @scardis/omnifocus-mcp@0.1.2).

Related to the dist/snippets packaging issue filed at #1 — unrelated bug, just flagging the connection since both surfaced from the same real-world usage.

Test plan

• npm test — all 144 unit tests pass (updated one existing TaskSummary fixture in schemas.test.ts to include the now-required completionDate field)
• Rebuilt, packed, and installed the .mcpb locally; verified against a real OmniFocus database:
  • list_tasks with filter.status: ["complete"] returns real completionDate timestamps
  • filter.completedAfter correctly narrows results (confirmed two known-earlier completions were excluded by a later cutoff)
  • containerId/containerType resolve correctly on completed tasks via both list_tasks and get_task (previously both came back null)

[steveardis]

Closing in favour of #6, which independently contains all three changes here: the containerInfo rewrite in get_task and list_tasks, completionDate on TaskSummary, and the completedAfter filter. Merging this and then #6 would conflict with itself in every file.

To be clear about what is being closed, because this PR is sound: I test-merged it against main and it merges cleanly, typechecks, and passes 150/150. The containerInfo rewrite is the right call — assignedContainer genuinely does come back null for completed tasks, and complete_task.js already used the parentTask/containingProject pattern you are introducing here, so this makes get_task and list_tasks consistent with code that was already in the tree.

Two notes worth carrying to #6:

• completedAfter returns nothing on its own. In list_tasks.js the status filter runs first and by default strips complete, so filter: { completedAfter: "..." } with no status always yields []. The description you added does not mention it, and the description is what the model reads.
• One semantic difference from Report effective completion date on parent-completed subtasks #6. You report the literal completionDate; Report effective completion date on parent-completed subtasks #6 reports effectiveCompletedDate, which also fires for a subtask whose parent was completed. Worth knowing that the field means something slightly different there.

One thing I would have asked for had this been merged on its own: it ships two behaviour changes with no new tests. The test count is unchanged at 150 — the only test edit is adding completionDate: null to an existing fixture, so neither the filter nor the containerInfo rewrite is covered. #6 adds seven tests, which is part of why it is the one to carry forward.

Thanks for both this and the diagnosis in #1 — that one is fixed and released in 0.2.0.