Align bevy_transform's feature flags

[Sieluna]

Objective

bevy_transform's multi-threading behavior was previously gated on feature = "std", which incorrectly conflated standard library availability with multi-threading capability. This means:

• Users who enabled no_std but had multi-threading available lost parallelism unintentionally.
• Users who had std but wanted single-threaded execution (e.g. WASM) still attempted to use the parallel path.
• bevy_internal's multi_threaded feature did not propagate down to bevy_transform, so the parallel implementation was not activated when expected.
• The bevy_log dependency was pulled in unconditionally via the std feature, when the only use was optional trace-level warnings.

Solution

• Added an explicit multi_threaded feature to bevy_transform, backed by bevy_tasks/multi_threaded, matching the pattern used by bevy_ecs and other crates.
• Replaced all #[cfg(feature = "std")] / #[cfg(not(feature = "std"))] guards on parallel/serial code paths with #[cfg(all(not(target_arch = "wasm32"), feature = "multi_threaded"))] / #[cfg(any(target_arch = "wasm32", not(feature = "multi_threaded")))] — the same guard pattern already used in bevy_ecs.
• Added bevy_transform/multi_threaded to bevy_internal's and bevy_render's multi_threaded feature lists so parallel transforms are activated end-to-end when building Bevy with multi_threaded.
• Removed the bevy_log dependency from bevy_transform. Its sole usage was a warn_once! inside propagate_transforms_for. This is replaced with a direct tracing::warn! wrapped in bevy_utils::once!, gated on a new opt-in trace feature (dep:tracing). This keeps the default build lighter.
• Inlined the trace feature spans in mark_dirty_trees that previously depended on bevy_log's re-exported tracing, now using tracing directly under #[cfg(feature = "trace")].

Testing

• All existing unit tests in bevy_transform::systems::test pass unchanged — no behavioral changes, only cfg guard corrections.
• No performance regressions observed by Benchmark.

---

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

[alice-i-cecile]

Can you say more about why it was helpful to remove this dependency in this PR? Does it not have no_std support?

[Sieluna]

The trace feature in bevy_transform is intentionally aligned with bevy_ecs, since bevy_transform is a sub-crate that should follow the parent crate's conventions:

bevy/crates/bevy_ecs/Cargo.toml

Line 39 in 64fe756

trace = ["std", "dep:tracing"]

bevy/crates/bevy_ecs/Cargo.toml

Line 124 in 64fe756

tracing = { version = "0.1", default-features = false, optional = true }

bevy_transform uses exactly the same pattern. The feature name, dependency declaration, and enable condition are identical.

bevy_log is a user-facing subscriber configuration crate — pulling it in for a single tracing::warn! adds unnecessary weight to a mid-graph crate that should stay minimal.

[alice-i-cecile]

Very clean, but needs a migration guide. Feature flags are a pain to try and diagnose during upgrades.

I'd also like a better understanding of the bevy_log situation.

[alice-i-cecile]

I don't think performance concerns are very relevant here. Did you see the comment from the bot above about the migration guide? We need to explain how users can migrate their feature flag setup.

[kfc35]

logic looks good