Split out the login routes into backend/src/routes/auth.ts #133

What this is for

backend/src/index.ts is one giant 2,300+ line file with every API route crammed into it. We're splitting it into smaller files, one per feature area, so it's easier to find and change things. This issue covers the login routes.

A finished example already exists — PR #117 did this exact thing for the "announcements" routes. Use it as your template.

Routes to move

Search backend/src/index.ts for these two routes and move them:

• POST /api/auth/login
• GET /api/auth/me

Steps

1. Create a new file backend/src/routes/auth.ts.
2. Copy the two routes above out of backend/src/index.ts into the new file, wrapped in an exported function, e.g.:

   import express from 'express';
   import { dbStore, ... } from '../db';
   import { getAuthUser, sanitizeUser, JWT_SECRET, JWT_EXPIRES_IN } from '../auth';
   
   export function registerAuthRoutes(app: express.Express) {
     app.post('/api/auth/login', async (req, res) => { /* ...unchanged... */ });
     app.get('/api/auth/me', async (req, res) => { /* ...unchanged... */ });
   }

3. In backend/src/index.ts, delete the two routes you just moved, add import { registerAuthRoutes } from './routes/auth'; near the top, and call registerAuthRoutes(app); where the routes used to be.
4. Don't change any logic — copy the code exactly as-is. This is just moving code to a new home, not rewriting it.

Watch out for

• getAuthUser, sanitizeUser, and JWT_SECRET already live in backend/src/auth.ts — import them from there, don't redefine them.
• The login route uses authRateLimiter — check whether that's still defined in index.ts and import it too if needed.

How to check your work

1. cd backend && npm run lint — must show no errors.
2. npm run build — must succeed.
3. Start the server locally against a scratch/test MongoDB (never the real one) and confirm with curl:
   • Logging in with a valid seeded account still returns a token.
   • GET /api/auth/me with that token still returns the user.
   • A wrong password still gets rejected the same way as before.

See PR #117 (#117) for exactly what a finished, verified PR like this should look like — including how to write up the test plan.

Part of #116.