### Overview `Component::preSave()` runs a sequence of self-healing config updaters (`CanvasConfigUpdater` methods). Their relative order is significant, but nothing documents it: - A heal that changes versioned settings creates a new active version (e.g. the `required`-flag heal), which changes what "the active version" is for every heal that runs after it. - A heal that derives data from the live implementation (e.g. the `derived_schema_metadata` backfill from #3591727) therefore produces different per-version outcomes depending on whether it runs before or after a version-creating heal: run first, the data lands on the soon-to-be-past version and is copied into the new one; run last, the past version is left without it. The same applies to *when* a heal runs relative to other write paths: the outcome can differ between auto-save operating on a component and `hook_post_update_N()` healing it, because each triggers the chain at a different moment. In !1300 the position of a new heal was chosen ad hoc, and the rationale for the existing order lives only in reviewers' heads — see the discussion at https://git.drupalcode.org/project/canvas/-/merge_requests/1300#note_1427697. Every future heal author faces the same undocumented decision. ### Proposed resolution Document the ordering contract on `Component::preSave()` (or the `ComponentPreSaveUpdate` attribute), rather than each individual heal: - Which heals create new versions and which mutate in place, and why that distinction determines what a later heal observes. - The default rule for new heals (append at the end) and what must be checked before deliberately inserting one earlier. Documentation only; no behavior change. ### User interface changes None.