fix(tw): isolate Taskwarrior data with TASKDATA and serialize CLI ops

[NaitikVerma6776]

Summary

• Stop using the shared /root/.task database: task now runs with TASKDATA and TASKRC inside each request temp dir (cmd.Dir alone was not enough).
• Remove rm -rf /root/.task from fetch/add/complete/delete/modify helpers.
• Serialize all Taskwarrior CLI helpers with a mutex so GET /tasks and mutation jobs cannot overlap.
• Log the real fetch error on GET /tasks; return [] instead of 500 when the task list is empty.

Fixes #471

Test plan

• go test ./utils/ ./utils/tw/ (Taskwarrior tests still need task on PATH)
• In the backend container: after a fetch/add, confirm TASKDATA is the temp dir (not /root/.task) and /root/.task is not deleted as part of the request
• Overlap GET /tasks with an in-flight add/edit; sync should not fail with SQLite 1032 from a concurrent wipe
• Empty task list still returns 200 with []
• Failed fetch still returns 500 and logs the underlying error

[github-actions]

Thank you for opening this PR!

Before a maintainer takes a look, it would be really helpful if you could walk through your changes using GitHub's review tools.

Please take a moment to:

• Check the "Files changed" tab
• Leave comments on any lines for functions, comments, etc. that are important, non-obvious, or may need attention
• Clarify decisions you made or areas you might be unsure about and/or any future updates being considered.
• Finally, submit all the comments!

More information on how to conduct a self review:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request

This helps make the review process smoother and gives us a clearer understanding of your thought process.

Once you've added your self-review, we'll continue from our side. Thank you!

[its-me-abhishek]

Hi, correct me if I'm wrong but: I think we should rather add the Get Tasks to the job queue instead of modifying the queue (for now)

Since the server was built quite early on -- when Tsc probably didn't support concurrency, I couldn't implement it here.

But the Get tasks seems to be quite a fast process, along with others hence never caused any issues for a single instance.

So migrating it to one job queue now may make sense, in order to make this a concurrent thing in future (next Gsoc, probably :) or before that)

So i guess migrating the GET tasks to the job queue, via some way (maybe change the request type-or add it to the queue via our methods defined in backend). LMK your thoughts on this.

[NaitikVerma6776]

@its-me-abhishek i have updated the implementation to use GlobalJobQueue for fetching tasks and added tests for panic handling and queue usability...The focused controller tests are passing and have verified the diff.
waiting for review