Split out the student routes into backend/src/routes/students.ts

[jgupta05072003-code]

What this is for

We're splitting the giant backend/src/index.ts file into smaller, feature-specific files. This one covers the student routes — the core, most-used domain in the whole app, with the most role-based access control (who can see/edit which students). Recommended: do a couple of the simpler issues from #116 first before tackling this one, and get a careful review before merging.

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:

• GET /api/students
• POST /api/students
• PATCH /api/students/:id
• PATCH /api/students/:id/profile
• POST /api/students/:id/diagnostic
• POST /api/students/:id/diagnostic/submit
• POST /api/paper/generate

Steps

1. Create backend/src/routes/students.ts.
2. Copy all the routes into a registerStudentRoutes(app) function, exactly like PR Start splitting backend/src/index.ts into route modules (announcements PoC) #117 did for announcements.
3. In index.ts, delete the routes, import registerStudentRoutes, and call it where they used to be.
4. Don't change any logic, any permission checks, or any data-scoping — copy the code exactly as-is.

Watch out for

• GET /api/students has different visible data per role (some roles see full contact info, some see it redacted, Aadhaar is masked for non-Superadmins) — this is the most important logic in the file to get byte-for-byte identical after the move.
• The by-ID routes (PATCH, diagnostic, diagnostic/submit) use canAccessStudent (from backend/src/auth.ts) to stop one school's staff from editing another school's students — make sure every one of those checks is still there after the move.
• This is the single most security-sensitive group in the whole list. Please ask for a careful review before merging, even after your own testing passes.

How to check your work

1. cd backend && npm run lint — no errors.
2. npm run build — succeeds.
3. Start the server against a scratch/test DB and, logged in as several different roles (Teacher, School, Block Admin, Superadmin, and one Teacher from a different school than the student you're testing with), confirm:
   • GET /api/students returns the same scoped/redacted data as before for each role.
   • A teacher editing a student from their own school still works.
   • A teacher trying to edit a student from a different school is still blocked (this is the important one — don't skip it).

See PR #117 (#117) for the exact pattern.

Part of #116.