ci: fix malformed backend-tests.yml so backend CI actually runs

[dadadave80]

Closes #2

Problem

.github/workflows/backend-tests.yml had job-step maps (- name: Upload test results, …) nested inside on.pull_request.paths where path globs belong. GitHub Actions parsed the file, found no valid jobs: block, and silently skipped the workflow — so no backend tests ran on any PR or push.

Fix

Restructured the file with a proper jobs: section, using the correctly-formatted e2e-tests.yml as reference:

• unit-tests — checkout → setup-node@v4 (Node 20, npm cache keyed on backend/package-lock.json) → npm ci → npm test, with coverage uploaded via upload-artifact@v4 (if-no-files-found: ignore).
• validate-compose — runs docker compose -f deployment/docker-compose.yml config.

Note on service containers

The issue's proposed fix added Postgres + Redis service containers. The backend test suite doesn't need them — backend/src/test/setup.ts points the DB at a temporary SQLite file, so the tests are fully self-contained. I left the services out to keep CI fast and the config honest; happy to add them if there's a planned suite that requires a real Postgres/Redis.

Verification

cd backend && npm ci && npm test
# Test Files  8 passed (8)
#      Tests  89 passed | 16 skipped (105)

Workflow YAML validated: valid jobs: block (unit-tests, validate-compose), paths is a list of globs.

[Uchechukwu-Ekezie]

Clean fix. The root bug was real — job-step maps were nested inside on.pull_request.paths which meant GitHub Actions never saw a valid jobs: block and silently skipped the workflow on every PR.

A few things I checked:

Structure — on: block is now correct: push and pull_request both have proper paths: lists as string arrays, not mixed with step maps.

unit-tests job — setup-node@v4 with Node 20, cache-dependency-path: backend/package-lock.json is the right scope. npm ci → npm test with NODE_ENV: test is clean. Coverage artifact with if-no-files-found: ignore is safe.

No Postgres/Redis services — the explanation in the PR description is correct. If src/test/setup.ts configures a SQLite temp DB, adding real service containers would be noise. That's the right call.

validate-compose — docker compose -f deployment/docker-compose.yml config is a dry-run parse, not a docker compose up. Correct choice for a CI validation step.

All three CI checks pass: Unit & Integration Tests ✓, Validate Docker Compose ✓, Playwright E2E ✓.

Good work @dadadave80.