fix(metadata): Use operation output DTO in ObjectMapperProcessor

[Spomky]

Q	A
Branch?	4.2
Tickets	none
License	MIT
Doc PR	not needed

This PR follows up on #7601 and applies the same fix to the ObjectMapperProcessor.

While #7601 addressed the provider side by properly using the operation output class when defined, the processor was still relying on $operation->getClass(). This change updates the processor to use the operation’s output DTO ($operation->getOutput()['class'] ?? $operation->getClass()), ensuring consistent behavior between providers and processors.

ping @yceruto

[yceruto]

Thanks @Spomky for addressing this 🤟

Yes, this will cover the use case of having a custom output DTO for state processors, but I just realized it will only work if a custom input DTO is also defined; otherwise, it won't reach the final lines where the output is mapped.

We may need to refactor the entire method to explicitly handle all possible combinations:

• no custom input and no custom output (supported) --> returns persisted data
• no custom input with a custom output (unsupported) <-- missing scenario, should return output DTO
• custom input with no custom output (supported) -> returns persisted data
• custom input with a custom output (adding support in this PR) -> returns output DTO

[yceruto]

I'm afraid that touching ObjectMapperMetadataCollectionFactory may also be necessary, since it is the one that sets map=true for this operation

[Spomky]

Correct.
I will update my PR.