MCP update_plan_tasks regenerates UUIDs, breaking milestone/context links

[jlunder00]

Bug

update_plan_tasks replaces the entire task list for an anchor, generating new UUIDs for every task. This breaks:

• milestone_tasks links (orphaned task_ids)
• task_context links (orphaned task_ids)
• task_dependencies (orphaned blocked_by/blocks references)

Repro

1. Create tasks via update_plan_tasks
2. Link tasks to milestones via link_task_to_milestone
3. Call update_plan_tasks again with the same anchor (e.g. to add one task)
4. All milestone links are now broken — old UUIDs no longer exist

Expected

Adding a task to an anchor should not destroy existing task UUIDs. Options:

1. Add an add_task MCP tool that appends without touching existing tasks (preferred — simple, no side effects)
2. Make update_plan_tasks preserve UUIDs by matching on task text and only creating new UUIDs for genuinely new tasks
3. Add upsert semantics — accept optional id field in the task list, preserve matching IDs

Impact

Any MCP client (Claude Code, Beacon, external tools) that calls update_plan_tasks to add/reorder tasks will silently break all relationship links. This makes milestone tracking unreliable.

Workaround

Use patch_task for modifying existing tasks. For adding new tasks, there is currently no safe MCP tool — must use the API directly.