Amaresh: Restore dropped eventRouter mount and fix its route ordering bug

[amaresh2001]

Description

Restores a real, fully-built Event API (GET/POST /api/events, /events/types, /events/locations, waitlist/registration endpoints) that was silently dropped from src/startup/routes.js during an unrelated merge (fix(1342): adjust backend logic, Nov 13 2025), the mount line and bmIssueRouter's mount both got dropped in that merge's conflict resolution; bmIssueRouter was restored later, eventRouter never was. This left the route unreachable (404) even though the controller, model, and 192 real event documents in the dev database were all already there and working. Also fixes a route-ordering bug inside eventRouter.js itself that was invisible while the router was unmounted: /events/:id was registered before /events/types and /events/locations, so Express matched those two literal paths as if "types"/"locations" were an :id param and routed them to getEventById instead, which threw a Mongoose CastError.

Related PRS (if any):

This backend PR is related to the frontend PR #5453 (amaresh/fix-event-participation-static-metrics-and-nav-links wires the Event Participation Analytics page to this restored API).
To test this backend PR, you need to check out the #5453 frontend PR.

Main changes explained:

• Update src/startup/routes.js for re-adding the eventRouter require and its app.use('/api', eventRouter) mount, restoring the route to reachable.
• Update src/routes/eventRouter.js for reordering the route registrations so /events/types and /events/locations are registered before the /events/:id wildcard, so they match their own handlers instead of being caught by it first.

How to test:

1. Check into the current branch.
2. Do npm install and npm run dev to run this PR locally.
3. With a valid session token, hit GET localhost:4500/api/events, GET localhost:4500/api/events/types, and GET localhost:4500/api/events/locations (Postman or curl -H "Authorization: <token>") all three should return real data instead of a 404, and /events/types//events/locations specifically should no longer 500/error out on a Mongoose CastError.
4. Alternatively, check out the companion frontend PR #5453 and log in as any user, then visit localhost:5173/communityportal/database/design this page (an already-shipped feature) that was broken by the same dropped mount and should now load real event cards with working Event Type/Location filter dropdowns instead of a "Failed to fetch filter" error.
5. Also visit localhost:5173/communityportal/reports/participation (needs the frontend PR) to see the same real data flowing into the Event Participation Analytics page.

Screenshots or videos of changes:

Note:

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[RuthwikHM]

Tested this out with the frontend PR. Issues documented there.
OneCommunityGlobal/HighestGoodNetworkApp#5453 (review)

[amaresh2001]

@RuthwikHM Thank you for testing. Replied on the frontend PR; the route responds correctly on this branch (200 on first load, 304 on cache revalidation, not a 404), and the page loads real data end-to-end. Likely a stale local build on the test side. Details in #5453.

[RuthwikHM]

This looks good to me. I did have a stale backend build running it seems so that got resolved. Found one really tiny bug though in the UI in dark mode. See this review for more information.

[DeMoliT1on]

Hi @amaresh2001 ,
Tested locally in Postman and verified that all the APIs are accessible.

Approved!