MSPCA-10 Add GET /volunteers/:id/matches endpoint

[Juwang110]

ℹ️ Issue

Closes MSPCA-10

📝 Description

Adds GET /api/volunteers/:volunteerId/matches, which returns every match for a volunteer with matchId, chameleonAnimalId, status, and deniedReason. A volunteer with no matches gets [] with a 200. An unknown volunteer gets a 404, and a non-numeric or non-positive id gets a 400.

Changes:

1. Added MatchesService.findByVolunteerId and VolunteersService.existsById. existsById is identical to the one in MSPCA-11 Add POST /recommendations endpoint #4, so the two PRs merge cleanly there. The 404 depends on whether the volunteer exists, not on whether the result is empty, which keeps "no matches" a 200.
2. VolunteersModule imports MatchesModule and CoordinatorsModule, and is now registered in AppModule. Before this, no feature module was mounted, so the route would never have been served.
3. Fixed PluralNamingStrategy.columnName, which ignored @Column({ name }). Every named column was queried by its camelCase property name ("volunteerId" rather than volunteer_id), so any query against a real DB returned a 500. This affects every entity. The same commit is on MSPCA-11 Add POST /recommendations endpoint #4.

✔️ Verification

• yarn test: all backend suites pass (20 suites, 154 tests), including new service and controller tests.
• yarn lint:check and yarn format:check are clean.
• Against a local Postgres with migrations applied, start npx nx serve backend and run:

  curl -i localhost:3000/api/volunteers/<id>/matches

  A volunteer with matches returned 200 with the matches, and one without returned 200 with []. An unknown id returned 404 and abc returned 400.

🏕️ (Optional) Future Work / Notes

[dburkhart07]

just a few smalls. Some general formatting and logic things that I pointed out in your other PR apply here too. Can you make sure those changes are reflected in this one as well?

[dburkhart07]

Can we make this use the ParseIntPipe and treat is as an integer instead?

[dburkhart07]

can we make sure that the repo.existsBy was not called in this case?

[dburkhart07]

i don't think we need to be testing the invalid ids. while it is good to, we already know validateId works. Let's remove these.