fix(pm): scope-guard misidentifies project IDs as task IDs & add Adminer to docker-compose

[AlexKalll]

Summary

Two changes: a fix for the ProjectScopeGuard that blocked Project Managers from viewing their project tasks, and a new Adminer service for local DB management.

1. Fix: ProjectScopeGuard false-positive on /project/:id routes

Problem

• Project Managers always received 403 "Task is not available" when opening their project's Tasks tab.
• Symptom: tasks could be created successfully (success toast) but never appeared in the list — because creation (POST /) has no :id param while listing (GET /project/:id) does.

Root cause

The guard resolved request.params?.id as a fallback taskId. On routes like:

• GET /project-mgmt/task/project/:id
• GET /project-mgmt/task/project/:id/all
• GET /project-mgmt/task/project/archived/:id

...the :id is a project UUID, so the guard queried the task table with a project ID → no row found → ForbiddenException('Task is not available') instead.

Fix

src/project/guard/ProjectScope.guard.ts

Only fall back to the generic :id param when the request path is not a /project/… route. Explicit task_id / taskId params are unaffected, and task-scoped routes (/:id, /:id/members, PUT /:id, …) still enforce project-manager ownership exactly as before.

2. Chore: Adminer service in docker-compose

Adds an adminer container for convenient local PostgreSQL inspection:

• Port mapping: 5555:8080
• Waits for the postgres healthcheck before starting (depends_on.condition)
• Joins the existing backend_network

Validation

• As ProjectManager: create a task → success toast
• As ProjectManager: open project Tasks tab → tasks now render instead of 403 Task is not available
• docker compose up -d adminer → reachable at http://localhost:5555