fix: conflict with rector/rector >=2.6.2 (#420)

[bbrala]

Stopgap for #420 so the next release installs and runs.

Rector 2.6.2 removed every version-specific set constant from its first-party extension packages in favour of the new composer-based sets (rectorphp/rector-phpunit#760). The Drupal 8, 9 and 10 configs reference those constants directly, so from 2.6.2 on they abort before any rule runs.

Verified boundary

Bisected against real installs rather than the release notes — 2.6.1 is the last release on which every Drupal set loads:

rector	Drupal10SetList::DRUPAL_100
2.5.9	ok
2.6.0	ok
2.6.1	ok — last working release
2.6.2	[ERROR] Could not detect twig set.
2.6.3 / 2.6.6	same failure

Breakage map on 2.6.6

Set	Result
DRUPAL_90, DRUPAL_100	Could not detect twig set.
DRUPAL_91, DRUPAL_92	Undefined constant …PHPUnitSetList::PHPUNIT_90
DRUPAL_101	Undefined constant …SymfonySetList::SYMFONY_63
DRUPAL_102	Undefined constant …SymfonySetList::SYMFONY_64
DRUPAL_8*, DRUPAL_103, all D11 / D12	ok

Plus the DRUPAL_8 / DRUPAL_9 / DRUPAL_10 aggregates that include the broken per-minor configs. The Drupal 11 and 12 sets reference no third-party sets and are unaffected.

The change

"conflict": {
    "rector/rector": ">=2.6.2"
},

A conflict rather than a narrowed require, so the supported range stays documented as ^2 and composer reports the incompatibility by name:

palantirnet/drupal-rector … conflicts with rector/rector 2.6.6.

Re-resolving ^2 now lands on 2.6.1.

Trade-off

>=2.6.2 also holds back Drupal 11 users who would otherwise be fine on 2.6.6. That is deliberate for a stopgap — a partial break where D9/D10 users hit a hard error is worse than a loud install-time refusal, and the alternative (defined() guards around the missing constants, as drupal-9.0-deprecations.php already does for TWIG_24/TWIG_240) would degrade silently.

Follow-up

The real fix is porting the sets to the composer-based mechanism, #419. Rector 2.6.6 already expects it: withComposerBased(drupal: true) resolves DrupalRector\Set\DrupalSetList::COMPOSER_BASED, and SetGroup::DRUPAL is now marked @deprecated Use composer-based.php set instead — so the current DrupalSetProvider / ComposerTriggeredSet approach is on the deprecated path upstream. The conflict is lifted once that lands.

Gates

• PHPUnit — 695 tests, 954 assertions, OK
• PHPStan — no errors
• php-cs-fixer — 1 pre-existing violation in RemoveToolkitArgFromImageToolkitOperationConstructorRector.php (null|int → ?int), confirmed present on main without this change

Reported by @ptmkenny.

---

Second commit: unrelated codestyle fix

The php-cs-fixer job was failing on code this PR does not touch, which blocked the branch. The @Symfony ruleset in php-cs-fixer 3.95.24 enforces nullable_type_declaration with the question_mark style; the dev constraint is ^3.95.1, so the rule arrived via a floating minor rather than any change here. RemoveToolkitArgFromImageToolkitOperationConstructorRector.php has been unchanged since it merged green, and only the php-cs-fixer job catches this — the scheduled runs cover phpstan, phpunit and functional tests only, so it went unnoticed on main.

Kept as its own commit (null|int → ?int, no behavior change) so it stays separable from the conflict change.