4. Policy contribution attribution

[BryanttV]

Description

• Tracking model: decide where the origin of each policy is stored — a separate DB table, an additional field on the Casbin policy, or metadata in the loaded-definitions registry?
• Special case: extending built-in roles: when a module adds a permission to a core role (e.g. adding courses.export_grades to the instructor role), the system must be able to distinguish "this came from core" from "module X added this," even after both permissions coexist in the same role.
• Downstream use of this attribution: consider whether this information should be exposed in the APIs so the Administrative Console can show "this permission was added by [module]" — this isn't explicitly required, but it helps debugging and auditing.
• Reversibility: even though plugin removal is out of scope, the attribution design should ideally not block that future capability.

Concrete deliverable: given any role or permission loaded in the system, its origin (core vs. specific module) can be queried programmatically.