Add test suite, bug fixes, and PATCH /tasks/:id/assign endpoint

[Satyamdixit2802]

Summary

Adds test coverage for the existing Task Manager API, documents bugs found during testing,
fixes one of them, and implements the new PATCH /tasks/:id/assign endpoint.

What's included

1. Tests (tests/)

• Unit tests for all taskService.js functions
• Integration tests (Supertest) for every route: GET /tasks (+ status/pagination filters),
  POST /tasks, PUT /tasks/:id, DELETE /tasks/:id, PATCH /tasks/:id/complete, GET /tasks/stats,
  PATCH /tasks/:id/assign
• Coverage:96.79% — see summary below / screenshot

2. Bug report (BUGS.md)

Found [N] bugs while writing tests. Full details with location, expected vs actual behavior,
and root cause are in BUGS.md. Summary:

• getByStatus uses substring matching (.includes()) instead of exact equality, so filtering
  by status can match unintended tasks
• getPaginated has an off-by-one: offset = page * limit skips the first page's worth of
  results instead of starting at 0
• completeTask unconditionally resets priority to medium, silently discarding the task's
  original priority

3. Fix

Fixed the pagination off-by-one in getPaginated (offset = (page - 1) * limit). Chose this
one because it's the most clear-cut and highest-impact — page=1 was previously returning the
second page of results, which would be a visible, confusing bug for any real client. Updated
tests to lock in the corrected behavior. Other bugs are documented but left unfixed per the
assignment scope.

4. New feature: PATCH /tasks/:id/assign

• Accepts { "assignee": "string" }, stores it on the task, returns the updated task
• 404 if task doesn't exist
• 400 if assignee is missing, non-string, or empty/whitespace-only
• Reassignment is allowed (no "already assigned" guard) — kept consistent with how update()
  and completeTask() already behave in this codebase, with no existing precedent for blocking
  overwrites
• Full design rationale in DESIGN_NOTES.md

Test results

Coverage

Notes on the process

• What I'd test next with more time: [e.g. concurrent update race conditions on the
  in-memory store, malformed JSON bodies, very large pagination limits]
• What surprised me: [e.g. the pagination bug, or the priority reset in completeTask]
• Questions I'd ask before shipping to production: [e.g. should the in-memory store be
  swapped for persistent storage before this goes live? should assignee validate against a
  real user list instead of accepting any string?]