After checking it more deeply, I'm not sure we will be able to fix that issue.
The "problem" is that CompositeProviderPrice is using referred componentid and providerid like ComponentProviderPriceDetail, which use it as PK, together with FK to CompositeProviderPrice and together with standalone FK to Provider and Component.
As you correctly find out, changing multi-fk association to ComponentProviderPrice change UQ flag also for associations to Provider/Component and vice-versa. Unfortunately, this is because of inner design where associations one-to-one vs one-to-many are managed through UQ flag, which was sufficient for all the years until now in your project.
The same issue can happen in BestComponentProvider, where you're sharing componentid and providerid for component/provider associations together with ComponentProviderPrice (in case you would decide to make one of the associations one-to-one).
Unfortunately, this is something we can't easily fix. This is something that would require a deep rework of some inner logic, but also something, which causes that a lot of other tasks will because much harder (because UQ switch will not work). I need to discuss it with my team but I can't promise any ETA for reworking this issue.
On the other hand, the solution for you is pretty easy (and based on my modeling experiences also the better one). You can introduce unique IDs for every entity you want to store and instead of sharing componentid and providerid in several entities, use these unique IDs and use componentId and providerid only as standalone foreign keys (maybe also introduce ComponentProvider entity, instead of referring with multi-pk).
I will let you know in case we will find a way how to fix that. Thanks for understanding.