Security P4 — Overrides: derive tutor identity from JWT + relationship checks

[franciszver]

Part of #59.

Part of the broken-access-control remediation epic. Depends on Phase 1. This is the only write-side identity-trust finding — highest integrity risk.

Findings addressed

• Potential fix for code scanning alert no. 15: Information exposure through an exception #7 overrides.py:36 (POST /overrides/) — tutor_id, student_id, and target_id are taken from the request body. The handler only checks that some user with tutor_id exists; the authenticated caller (current_user) is never compared to it. Result: any tutor can attribute an Override audit record to another tutor and overwrite arbitrary Summary.next_steps/narrative or PracticeAssignment.ai_question_text/ai_answer_text for any student.
• Potential fix for code scanning alert no. 16: Information exposure through an exception #8 overrides.py:147 (GET /overrides/{student_id}) — returns any student's override history with no tutor↔student relationship check.

Work

• Derive tutor_id from the authenticated JWT (current_user → DB user); ignore/validate any body-supplied tutor_id.
• Validate student_id and target_id against a TutorStudentAssignment (src/models/tutor_student.py) before mutating Summary/PracticeAssignment or committing the Override.
• Apply the same relationship check to the GET history route.

Definition of Done

• override.tutor_id always equals the authenticated caller.
• Mutations rejected (403) when the caller has no assignment to the target student.
• GET history returns 403 for unrelated tutors; owner/admin works.

Affected files

src/api/handlers/overrides.py, src/models/tutor_student.py

[franciszver]

Done and merged to main in PR #66 (part of epic #59).