fix(metadata): format-agnostic uriTemplate match

[soyuka]

Q	A
Branch?	5.0
Tickets	n/a
License	MIT
Doc PR	n/a

itemUriTemplate and ApiProperty::uriTemplate are resolved to an Operation by comparing the configured string to Operation::getUriTemplate() with a strict ===. Auto-generated operations store the format suffix, so this never matches:

#[ApiResource(operations: [
    new GetCollection(itemUriTemplate: '/books/{id}'),  // stored target is '/books/{id}{._format}'
    new Get(),
])]

OperationMetadataFactory::create() then returns null, and IriConverter::getIriFromResource() silently falls back to the resource's default item operation. The result is a wrong @id, not an error — which is why this is easy to miss. The same strict comparison in ResourceMetadataCollection::getOperation() affects ApiProperty::uriTemplate in the JSON-LD and JSON:API normalizers.

Both call sites now keep the first candidate that matches once the {._format} or .{_format} suffix is stripped from both sides, and return it only after the full scan has found no exact match. Exact matching therefore still wins globally, so two operations differing only by the suffix keep their identities whatever their declaration order. The suffix stripping lives in a new @internal ApiPlatform\Metadata\Util\UriTemplateHelper, which UriTemplateResourceMetadataCollectionFactory now shares instead of carrying its own copy.

Functional coverage is tests/Functional/ItemUriTemplateWithoutFormatSuffixTest.php. Its fixture declares a collection whose itemUriTemplate omits the suffix, plus two item GETs so the fallback is observable. Before the fix:

-'/uri_template_format_suffix_resource_items/1'
+'/uri_template_format_suffix_resources/1'

Unit tests cover the lenient hit, the .{_format} spelling, exact-wins-over-lenient in both declaration orders, and the unchanged null/OperationNotFoundException behaviour for an unrelated template.