[christianbeeznest]

REST v2 class-management endpoints allowed any authenticated API user to inspect and modify class membership and course/session bindings.

This could be used by a regular student to add users to arbitrary classes or bind courses to classes. Course bindings can cascade into course enrollments through UserGroup::subscribe_courses_to_usergroup().

This change protects the following administrative endpoints with the existing protectAdminEndpoint() guard:

• get_group_sub_users
• get_group_sub_courses
• get_group_sub_sessions
• add_group_sub_user
• add_group_sub_course
• add_group_sub_session
• delete_group_sub_user
• delete_group_sub_course
• delete_group_sub_session

add_group and delete_group were already protected and were not changed.

Verified against a running 1.11.x instance:

• A non-admin authenticated REST user was rejected by all 9 affected endpoints.
• No class-user, class-course, class-session, or cascaded course enrollment rows were created by the rejected requests.
• A platform administrator could still add a user to a class and bind a course to the class.
• The expected course-enrollment cascade occurred for the authorized administrator action.
• The administrator could read the resulting class membership/course bindings and remove them again.
• All temporary class relationships and the cascaded course enrollment were removed after testing.
• php -l passed.
• git diff --check passed.

No existing session was available in the local test database, so the positive add/delete class-session binding path was not exercised at runtime. The non-admin session-binding endpoints were verified as rejected.

The legacy REST endpoint returns authorization failures as HTTP 200 with error=true; this change preserves that existing transport behavior.

Refs GHSA-4335-6683-mvwx