RemoveConfigSaveTrustedDataArgRector should not BC-wrap save() ($has_trusted_data is only a perf hint)
## Problem `RemoveConfigSaveTrustedDataArgRector` strips the deprecated boolean `$has_trusted_data` argument from `Config::save()` calls (`$config->save(TRUE)` → `$config->save()`). Today the rewrite is wrapped in a `DeprecationHelper::backwardsCompatibleCall()`: ```php // before $config->save(TRUE); // after (current) \Drupal\Component\Utility\DeprecationHelper::backwardsCompatibleCall( \Drupal::VERSION, '11.4.0', fn() => $config->save(), fn() => $config->save(TRUE), ); ``` The BC wrapper is unnecessary here. `$has_trusted_data` is purely a **performance hint**: passing `TRUE` tells `Config::save()` that the data is already cast to its schema types so the cast can be skipped. Re-casting already-typed data is **idempotent**, so calling `save()` (which re-casts) produces the same stored configuration as `save(TRUE)`/`save(FALSE)` on every Drupal version that ships `Config::save()`. The replacement is therefore always safe and the wrapper just adds noise. Confirmed with **berdir**. ## Expected The rector should emit a plain call: ```php // after (desired) $config->save(); ``` ## Idempotency Code already converted while the rector still emitted a BC wrapper must be left untouched — the deprecated `save(TRUE)` call lives in the `deprecatedCallable` arm of `backwardsCompatibleCall()`, and re-running the rector must not collapse the wrapper. The existing `AbstractDrupalCoreRector::isInBackwardsCompatibleCall()` guard already skips that arm, so this is handled by disabling BC wrapping for this rule. ## Fix Override `supportBackwardsCompatibility()` to return `false` on `RemoveConfigSaveTrustedDataArgRector` so the replacement is emitted directly, and update the fixtures (plain output + an `already_converted` no-change fixture proving idempotency). Refs change record [node/3348180](https://www.drupal.org/node/3348180), deprecation [node/3347842](https://www.drupal.org/node/3347842).
issue