Invert dependency direction: reduce openedx-authz's coupling to openedx-platform internals

Context

openedx_authz currently imports from edx-platform internals to implement behavior that's really owned by one consuming service's domain. PermissionValidationMeView's course-authoring flag awareness is an example of this: a generic-looking endpoint (validate an action against a scope) ended up CMS-specific in behavior, and authz had to reach into openedx-platform to check a flag that belongs to Studio's domain, not to the API itself.

The dependency direction is usually backwards from where it should end up. Consumers (edx-platform, frontend-app-admin-console, and any future consumer) should depend on and extend authz, not the other way around. Right now it's the reverse for at least this one case, and the REST API surface in general was designed around the admin console MFE's current, entirely CMS-oriented needs, so more cases like this are likely to show up as that surface grows.

Definition of Done

• Document which parts of the current openedx_authz REST API surface are CMS-specific rather than generic (course-authoring flag awareness is one, there may be others).
• Propose how that logic should be owned. Either move it into openedx-platform's own domain code, or expose an extension point in openedx-authz that each service implements, instead of hardcoding it into a supposedly generic endpoint.
• Record a decision (ADR or equivalent) on whether generic endpoints like permissions/validate/me need a per-service extension point, so this doesn't keep growing as more service-specific conditionals.

Start with PermissionValidationMeView and the permissions/validate/me endpoint, then inspect the current openedx_authz REST API surface for CMS-specific behavior such as course-authoring flag awareness. Document the affected areas, compare ownership or extension-point options, and record the decision in an ADR or equivalent.