Actually resolve dev dependencies in the dedicated CI job

[Amoifr]

Q	A
Bug fix?	yes
New feature?	no
Deprecations?	no
Issues	Fix #687
License	MIT

As reported in #687, the phpunit-dev CI job does not actually test against dev dependencies.

The job runs composer config minimum-stability dev before installing, but composer.json already declares minimum-stability: dev together with prefer-stable: true. Since dev versions are already allowed, that step is a no-op, and prefer-stable: true makes Composer install the stable releases anyway.

I verified this locally: with the current setup the job resolves symfony/dom-crawler to v8.1.1 (stable), while disabling prefer-stable resolves it to 8.2.x-dev. This is what let the Symfony 8 incompatibility from #685 slip through the "dev dependencies" job.

This replaces the redundant minimum-stability step with composer config prefer-stable false, so the job resolves the actual *-dev versions.

Note: since the job only becomes meaningful now, it may surface incompatibilities that were previously hidden. #685 is already fixed, and the sources lint cleanly against the dev versions, but the browser-based tests can only be validated by a real CI run here.

[Amoifr]

Heads-up on the CI result of this PR: with the job now resolving the actual *-dev versions, it does its job and turns red where it was previously (silently) green.

• 8.1 / 8.2 / 8.3 dev-dependency jobs: green
• 8.4 / 8.5 dev-dependency jobs: red

So this immediately surfaces an incompatibility that the old setup was hiding (it was testing symfony/dom-crawler v8.1.1 stable instead of 8.2.x-dev). The PHP-version split (older PHP green, 8.4/8.5 red with the same dev deps) makes me think it is most likely PHP 8.4/8.5 deprecations escalated to failures by the phpunit-bridge, rather than a hard breakage, but I could not confirm the exact failing assertions from here (fork PRs do not expose the base-repo run logs, and the browser-based tests need a driver I cannot run locally).

I did not open a separate issue for this, since the red CI here already puts it in front of you on the right thread. How would you prefer to handle it?

1. merge this CI fix and address the 8.4/8.5 failures separately (I am happy to open a focused issue or PR), or
2. keep it all together and I look into the failures within this PR.

Either way works for me. The important part is that the phpunit-dev job is now actually testing dev dependencies.

[Amoifr]

Coming back to this with the actual cause, my guess above was wrong. The 8.4 and 8.5 jobs did not fail on escalated deprecations, they died on a hard fatal:

PHP Fatal error: Cannot override final method Symfony\Component\DomCrawler\Field\ChoiceFormField::addChoice()

The job had resolved symfony/dom-crawler 8.2.x-dev 77ca351, a snapshot from 29 May where addChoice() was final. symfony/symfony#64443 removed that keyword on 4 June, and both 8.1 and 8.2 now declare public function addChoice(\DOMElement $node): void, so a fresh run of this job should get past it.

That also means this PR and #695 overlap, @nicolas-grekas: yours sets prefer-stable: false in composer.json for everyone, mine only forces it in the dedicated dev dependencies job so the other jobs keep testing stable releases. Would you rather merge #695 and I close this one, or keep the job scoped variant? Happy either way, and #695 landing first is fine by me since it is the one that would have caught the break.