Use early exit when collecting the registered class loaders

[SanderMuller]

The Coding Standard job is red on 2.2.x after c10897b (#6281 - my fault, the fix was on the branch but not in the merged commit):

FILE: src/autoloadFunctions.php
 111 | ERROR | [x] Use early exit to reduce code nesting.
     |       |     (SlevomatCodingStandard.ControlStructures.EarlyExit.EarlyExitNotUsed)

The collect loop is inverted to if (!isComposerClassLoader(...)) { continue; }, and the boundary lookup - a foreach nested in an if - becomes findClassLoaderIndex(), which returns early. No behaviour change.

Verified: phpcs over the whole repo reports the error on the current tip and nothing with this change; CollectNewAutoloadFunctionsTest 6/6; self-analysis clean; e2e/bug-15102 still green.

[ondrejmirtes]

Thank you!

[SanderMuller]

While checking which CI reds were mine, I measured the one remaining base failure and filed it as phpstan/phpstan#15119: Run with Turbo Extension (macos-latest, 8.5, nts, make phpstan) is an OOM at the Makefile's own memory_limit=450M, not an analysis failure. Same commit and command, peak RSS: 420 MB without the extension, 449.5 MB with the CI-built macOS one - so the cap is already met and turbo consumes the remaining headroom.

Your call which side moves (raise the cap, or find the 30 MB) - I did not want to pick, since the cap doubles as a memory-regression guard. Happy to send either, or to bisect self-analysis peak from 2.2.9 to now if that is the more interesting question.

For the record, the rest of the reds on this PR are not from it: the 14 integration jobs are the class.nameCase family that phpstan/phpstan#15103 refreshes baselines for, the doctrine lane waits for 2.2.10, bug-11826 is the fork-worker fatal capture, and the 9 issue-bot Analyse shards were artifact 403s that have since gone green.