feat: classroom control

[marikola]

Backend for classroom control, should be merged at the same time as feat: classroom control #69 on frontend to avoid issues for pupils not yet in classroom.

[johanaam]

A few things:

• The rule that a pupil can only join a new classroom when they are not active in another classroom is not enforced in the backend. joinClassroom only checks whether the pupil is already a member of the target classroom. If this is an important product invariant, the service should guard it explicitly.
• PupilProfile.currentClassroom and classroom_pupils.status now act as two related sources of truth. The code manually keeps them in sync during approval/removal, which is easy to break later. We should either make the relationship very explicit in the service or derive one from the other where possible.
• CurrentUserProfileService.findMembership() returns the first active membership anywhere, otherwise the first pending membership anywhere. That means membershipStatus may not describe the same classroom as currentClassroomId, which makes the API response ambiguous.
• ClassroomController still fetches pupil profiles directly when building classroom details. That lookup belongs in the service layer so the controller stays thin.
• Some updated tests pre-seed currentClassroom, which makes it harder to verify that join/approval behavior is actually doing the right thing. It would be better to assert the intended pending and approved states directly.

I got help from Codex finding these.

[marikola]

A few things:

• The rule that a pupil can only join a new classroom when they are not active in another classroom is not enforced in the backend. joinClassroom only checks whether the pupil is already a member of the target classroom. If this is an important product invariant, the service should guard it explicitly.
• PupilProfile.currentClassroom and classroom_pupils.status now act as two related sources of truth. The code manually keeps them in sync during approval/removal, which is easy to break later. We should either make the relationship very explicit in the service or derive one from the other where possible.
• CurrentUserProfileService.findMembership() returns the first active membership anywhere, otherwise the first pending membership anywhere. That means membershipStatus may not describe the same classroom as currentClassroomId, which makes the API response ambiguous.
• ClassroomController still fetches pupil profiles directly when building classroom details. That lookup belongs in the service layer so the controller stays thin.
• Some updated tests pre-seed currentClassroom, which makes it harder to verify that join/approval behavior is actually doing the right thing. It would be better to assert the intended pending and approved states directly.

I got help from Codex finding these.

Ok, I have updated the join classroom to check whether the pupil has any memberships already, and the findMembership method in CurrentUserProfileService to throw if it finds more than one membership, so there should not be any issues of mismatches between status and classroom, or any pupil joining more than one classroom. I´m not sure which tests you're referring to? If you specify I could update some :)