Fix transform systems ordering

[waynemwashuma]

Objective

Introduce a dedicated transform system group and explicit transform ordering to guarantee deterministic transform propagation behavior across the engine. This also prepares the scheduling pipeline for future ordering integrations with rendering, physics, animation and runtime schedule inspection tooling.

Solution

Previously, transform synchronization and propagation systems relied primarily on implicit registration order. This made execution ordering dependent on registration sequence and plugin initialization order, which becomes fragile as more engine systems integrate with transforms.

Changes made

Introduced TransformSystems system group

This group acts as a stable scheduling anchor for transform-related systems. The group is registered on the update schedule.

Added explicit transform ordering

Transform propagation systems now explicitly depend on transform synchronization systems. This guarantees propagation always executes after local transforms are synchronized.

Why this approach

Using a dedicated transform system group provides:

• a stable ordering target for external systems
• clearer execution semantics
• easier runtime inspection/debugging
• safer future schedule manipulation

Explicit ordering constraints are preferred over implicit registration order because they:

• document dependencies directly
• prevent accidental ordering regressions
• scale better as engine subsystems grow

This also aligns transform scheduling with the newer schedule graph architecture.

Showcase

N/A

Migration guide

No migration required.

Checklist

• I have updated the documentation accordingly.
• I have added tests to cover my changes.