Role-agnostic API behavior

Description

• Audit of existing code: review the listing, validation, assignment, and filtering paths for roles, looking for:
  • Comparisons like if role == "instructor" or hardcoded lists of valid roles.
  • Conditional branches specific to a role name.
  • Validations that assume a fixed, known set of roles at write time.
• Refactor: replace those comparisons with lookups against the dynamically loaded definitions.
• Risk to watch: this kind of hardcoding tends to be scattered across several modules (serializers, DRF permissions, form validators) — worth doing an exhaustive grep before estimating this as "done."
• Regression: current built-in roles must keep working exactly the same after the refactor — this task carries high risk of breaking existing functionality if not covered by regression tests.

Concrete deliverable: no AuthZ endpoint has code that depends on knowing a specific role name in advance; everything resolves against the loaded definitions.