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