bug: set_task_status can drift from tasks.json and next_task can return master for tagged runs

[Milgauss]

### Description

In a multi-tag workspace, I am seeing two related MCP consistency issues:

1. `set_task_status` can return success even when `.taskmaster/tasks/tasks.json` does not change.
2. `next_task(tag="phase3")` can respond in `master` context instead of the requested tag.

This makes the MCP unsafe to trust without re-reading the on-disk `tasks.json`.

### Steps to Reproduce

1. Use a multi-tag `tasks.json` (for example `master`, `phase2`, `phase3`).
2. Call:

```json
{
  "server": "user-task-master",
  "toolName": "set_task_status",
  "arguments": {
    "projectRoot": "/Users/andy/Projects/pinescrow-transactions",
    "tag": "phase3",
    "id": "41",
    "status": "pending"
  }
}

3. Immediately call get_task for task 41 on phase3.
4. Immediately re-read .taskmaster/tasks/tasks.json.
5. Call:

{
  "server": "user-task-master",
  "toolName": "next_task",
  "arguments": {
    "projectRoot": "/Users/andy/Projects/pinescrow-transactions",
    "tag": "phase3",
    "file": "/Users/andy/Projects/pinescrow-transactions/.taskmaster/tasks/tasks.json"
  }
}

Expected Behavior

• set_task_status should update both MCP reads and the on-disk file consistently.
• get_task should match the durable file after a successful write.
• next_task(tag="phase3") should stay in phase3 context and respect completed cross-tag dependencies.

Actual Behavior

• set_task_status returns success, but get_task and .taskmaster/tasks/tasks.json can still show the old status.
• next_task(tag="phase3") can return a response tagged master.
• In the same workspace, next_task(tag="phase3") reported no eligible task even though pending phase3 tasks had dependencies already completed in phase2.

Screenshots or Logs

Representative symptoms:

• set_task_status(id="41", status="pending") returned success
• get_task("41", tag="phase3") still reported done
• .taskmaster/tasks/tasks.json still showed done
• next_task(tag="phase3") responded with tag: "master"

Environment

• Task Master version: 0.43.1
• Node.js version: v25.8.1
• Operating system: macOS (Darwin 24.6.0)
• IDE (if applicable): Cursor

Additional Context

This seems related to:

• bug: MCP server stale in-memory tag state causes cross-tag data corruption #1637 stale in-memory tag state
• bug: add_task response 'tag' field shows previous active tag, not target tag #1638 wrong tag in MCP responses

The additional symptom here is that set_task_status acknowledgements can also disagree with both get_task and the durable file.

[github-actions]

Found 2 possible duplicate issues:

1. bug: MCP server stale in-memory tag state causes cross-tag data corruption #1637
2. bug: add_task response 'tag' field shows previous active tag, not target tag #1638

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with [Task Master Bot]

[Milgauss]

The issue is not a duplicate — it adds a third distinct symptom: set_task_status returning success while both get_task and the on-disk file still show the old status. That write-acknowledgement/file divergence is not covered by either #1637 (stale in-memory tag state) or #1638 (wrong tag in responses). It's a related but separate bug surface.