v1.0.3 - High Risk Action Hardening

Course deletion and role assignment now sit behind a dedicated capability, with
the editor and manual-run paths locked and the assign-role check pinned to the
action's configurer. This completes the high-risk-action hardening begun in 1.0.2.

🔒 Security

• High-risk rules are read-only without the capability. The
  tool/automate:managehighrisk gate added in 1.0.2 only governed the action
  picker, so a delegated manager who lacked it could still save the rule form
  (including the Enabled checkbox), conditions, logic and trigger of a
  pre-existing high-risk rule — enabling or broadening it until it fired. The
  editor now treats any rule that already contains a high-risk action as
  read-only for users without the capability: every mutating request (rule,
  condition, logic, trigger or action save, and condition/action deletes) is
  refused server-side, and the editable forms, pickers and edit/delete controls
  are replaced by a read-only view. Full site admins are unaffected.

• Manual runs are gated too. The editor lock would be moot if the rule could
  still be fired from the overview, so run.php now requires
  tool/automate:managehighrisk for a live run (dryrun=0) of any rule
  containing a high-risk action, and the overview hides that rule's Run now
  button for users without it. Preview (dry run) makes no changes and stays
  available. Cron and event triggers are unchanged.

• Assign-role validation pinned to the configurer. The run-time role
  re-check now validates the stored role against the assignable set of the user
  who configured the action, not the rule's usermodified (which every save
  rewrites to the current editor). A more privileged user re-saving an unrelated
  part of a rule can no longer widen what a stored role may grant. Legacy actions
  saved before this field existed fall back to the rule's last editor.

🛡️ Privacy

• The configurer id newly stored on assign-role actions is declared in the
  privacy metadata and is discovered, exported and anonymised by the privacy
  provider, so subject-access export and erasure requests now cover it.

⬆️ Upgrade notes

• No database schema change. After upgrading, high-risk actions
  (delete course, assign role) require the new
  tool/automate:managehighrisk capability, which no role holds by default —
  full site admins retain access. Grant it explicitly to any delegated role that
  should configure or run these actions.
• Requires Moodle 5.0–5.2 (PHP 8.2+; 5.2 requires PHP 8.3+).

Full changelog: CHANGELOG.md