Feat: Implement Assignee Filtering in `GET /tasks` Endpoint

[Achintya-Chatterjee]

Issue Description

The current GET /tasks endpoint does not support filtering tasks by assignee. To support the new frontend requirement of filtering the team todo list by one or multiple assignees, the backend needs to be updated to accept and process assignee-based filtering parameters.

Expected Behaviour

• The GET /tasks endpoint should accept a new query parameter, e.g., assigneeId (which can be repeated for multiple values, e.g., ?assigneeId=123&assigneeId=456).
• The TaskListView in todo/views/task.py should parse this parameter.
• The TaskService.get_tasks method should accept this list of assignee IDs.
• The TaskRepository.list method should filter the returned tasks to include only those where the assignee matches one of the provided IDs.
• Database Context: The application uses a dual-write system (MongoDB + PostgreSQL), but reads are exclusively performed against MongoDB (TaskRepository). The new filtering logic must be implemented in TaskRepository (MongoDB) to maintain consistency.
• Sorting Context: Sorting is already implemented in TaskRepository.list for fields like priority and updatedAt. Assignee sorting is currently disabled (SORT_FIELD_ASSIGNEE), which is acceptable as the requirement is only for filtering.
• Since assignees are stored in the task_assignments collection, the repository logic needs to query this collection to find matching task IDs, or we should use an aggregation pipeline to filter effectively.
• The filter should work in combination with existing filters like teamId and status.

Current Behaviour

• The TaskListView (todo/views/task.py) accepts teamId, status, page, limit, sort_by, and order.
• The TaskRepository.list (todo/repositories/task_repository.py) builds a MongoDB query based on these parameters.
• There is no logic to handle assigneeId filtering.
• TaskRepository has a helper _get_assigned_task_ids_for_user which gets tasks for a specific user (the requester), but this is for permission/visibility, not for an arbitrary filter.

Screenshots

N/A

Reproducibility

• This issue is reproducible
• This issue is not reproducible

Steps to Reproduce

1. Send a `GET` request to `/tasks?assigneeId=`.
2. Observe that the `assigneeId` parameter is ignored, and tasks are not filtered by the assignee.

• [] Critical
• High
• Medium
• Low

Additional Information

• Files to modify:
  • todo/views/task.py: Update TaskListView and extend_schema parameters.
  • todo/services/task_service.py: Update get_tasks signature and logic.
  • todo/repositories/task_repository.py: Update list and count methods.
  • Since TaskAssignmentRepository holds the mapping, we might need to first query TaskAssignmentRepository for all task IDs assigned to the provided assigneeIds (and filtered by teamId if present).
  • Then, use this list of task IDs in the $in clause of the main TaskRepository query.
  • We should be mindful of performance if the number of tasks is large; however, for a team's to-do list, I think it should be manageable.

Checklist

• I have read and followed the project's code of conduct.
• I have searched for similar issues before creating this one.
• I have provided all the necessary information to understand and reproduce the issue.
• I am willing to contribute to the resolution of this issue.