Add CI workflow that type-checks and runs unit tests on every PR

[Fran19-09]

🔗 Related Issue

Closes #145

---

🔖 Title

Add a CI workflow that runs the test suite and build on every PR

---

📝 Description

.github/workflows/ only contained leaderboard.yml — no workflow ran jest or a build/type-check on pull requests, so nothing stopped a PR with failing unit tests or a broken TypeScript build from being merged.

Added .github/workflows/ci.yml, triggered on pull_request against main, running npm ci, a type-check, and the unit suite.

---

🔄 Changes Made

• Add .github/workflows/ci.yml triggered on pull_request against main
• Run npm ci and npx tsc --noEmit as the build/type gate
• Run npx jest --runInBand (343 unit tests) and fail on any failure
• E2E suite: not wired into CI — see Notes
• Branch protection: not done in this PR — see Notes

---

📸 Screenshots (if applicable)

N/A — CI configuration, no UI.

---

🗒️ Additional Notes

• Build step is type-check only, and will currently fail on main. npm run build (nest build) fails today on the pre-existing @fastify/helmet v13 / fastify v4 mismatch (Fix @fastify/helmet v13 / fastify v4 version mismatch breaking local dev and build #146, submitted alongside this PR). npx tsc --noEmit hits the exact same type error, so this check will be red until Fix @fastify/helmet v13 / fastify v4 version mismatch breaking local dev and build #146 merges — at that point this step can go back to a full npm run build. I left it in rather than dropping the step entirely so the workflow's intended shape lands now and only needs a one-line swap once Fix @fastify/helmet v13 / fastify v4 version mismatch breaking local dev and build #146 is in.
• E2E suite is intentionally excluded. I checked every spec under test/e2e/: aside from health.e2e-spec.ts (which boots the full AppModule), most of the others still instantiate real feature modules (not mocks) and hit the same SupabaseService — they fail with supabaseUrl is required without a live Supabase project, and a couple of the loan-lifecycle/job specs additionally need a running Redis for BullMQ. Neither is available in this CI environment, so per the issue's own fallback I've documented this in the workflow and left npm run test:e2e as a local-only step against a real Supabase/Redis instance.
• Required status checks: making this workflow required on main needs branch protection settings, which I don't have access to configure as a contributor — a maintainer will need to add it once this merges.

[Fran19-09]

Cherry-picked the @fastify/helmet fix from #146 onto this branch so the build step isn't blocked on that PR merging first. Switched the workflow back to a full npm run build (verified green locally: build + 343 unit tests pass). Once #146/#151 merges into main, this duplicate commit will drop out cleanly on rebase.

[Josue19-08]

Solid CI setup for #145. Good call keeping tsc --noEmit as the build gate for the first two commits (since nest build was red on main from the pre-existing fastify/helmet mismatch) and then cherry-picking #146's fix onto this branch to restore a full npm run build once the type mismatch was resolved — that's exactly the right sequencing so this workflow lands green from day one instead of merging already-broken. The e2e-suite exclusion is well-justified and documented (real Supabase/Redis dependency, not available in this CI environment) rather than silently skipped. CI itself is green on this PR (test-and-build: SUCCESS).

Approving and merging. Since this branch already includes #146/#151's fix commit, I'll merge this first and then reconcile #151 separately.

[Josue19-08]

Approved above — the workflow itself is correct and CI is green. However #152 merged into main in the meantime, so this branch (which already had #146/#151's fix cherry-picked) now has a merge conflict, likely in package.json/package-lock.json against #152's dependency cleanup. Please rebase onto main and resolve it. I'll merge once it's pushed and CI is green again.