fix(symfony): pass operation priority to the route collection

[soyuka]

Summary

ApiLoader::load() called $routeCollection->add($operationName, $route) without passing the operation priority, so Operation::getPriority() was silently dropped and route ordering ignored any configured priority.

Reproduction

An operation declared with a higher priority was registered in the RouteCollection with priority 0, so it was not sorted ahead of other routes as expected.

Test plan

• Added failing test asserting the route records the operation priority.
• Test passes after the fix.
• tests/Symfony/Routing suite still passes locally (31/31).

Fixes #8135

[soyuka]

Closing this — it is the wrong fix.

Operation priority is already honored on 4.3 via Operations::sort() (src/Metadata/Operations.php:108, introduced by #6206 "fix(metadata): Operations priority sort"). Operations are sorted by getPriority() before being registered, so the sorted order becomes the route insertion order, which is the matching precedence.

Passing $operation->getPriority() again at the RouteCollection::add() level double-applies priority and, because RouteCollection::all() sorts priority descending while Operations::sort() sorts ascending, it scrambles the already-correct order. This breaks 6 functional tests (testGetPrioritizedOperation, subresource/custom-identifier route matching such as /employees/1/company, slug subresources) — the existing OperationPriorities fixture from #6206 starts hitting the wrong operation.

The reporter's report was against 4.0, which predates #6206. The path described is already fixed on 4.3.