There isn’t a problem. The call ID is completely valid. Anything not accepting it, or expecting it to have any semantics beyond being a globally unique identifier for the call, is broken.
Even when it contains @, there is no requirement that what follows the @ be a domain name:
Call-ID = ( "Call-ID" / "i" ) HCOLON callid
callid = word [ "@" word ]
Several examples in the SIP RFC contain no domain part.
As you already know from_user parameter will override any user setting, but why your provider doesn’t take the display name from the Remote Party ID header, assuming he just wants this information only for caller id purposes
I suspect the provider is abusing the display name to carry the real caller ID, or even more confusing, the account name.
We need to know how the provider is abusing it, to give any real help, and even then we might need to know if they have alternative mechanisms, for a good answer.