1. Role and permission definition ADR

[BryanttV]

Description

This task is the foundation for the whole epic. It requires making concrete decisions about:

• Declarative definition format: validate whether the YAML proposed in the document (roles, permissions, scope, display_name, description, resource) is sufficient or needs additional fields (schema version, contributing module namespace, etc).
• Stable identifiers: define the naming convention for roles and permissions (e.g. course_observer, courses.view_course) so they don't collide across different modules.
• Action inheritance: decide whether one permission can inherit from another (e.g. courses.edit_course implies courses.view_course) and how that's expressed in the schema. - we currently DO NOT support this so this might be a separate effort (out fo scope)
• Contribution attribution: decide what metadata gets stored to know which module contributed which role/permission.
• Boundary for extending built-in roles: define how far a module can go in adding permissions to a core role without breaking security guarantees — can a third-party module extend the instructor role without restrictions?
• Conflict handling: even though the document leaves this as an "open decision," the ADR should at least propose an initial stance (hard-fail on load? last-write-wins? require namespacing?).
• Minimum required validations: duplicate identifiers, references to undefined permissions, unsupported scope types, conflicting metadata — the ADR should specify what happens in each case (hard-fail error vs. warning).

Concrete deliverable: ADR document approved by the team.