I still can't reproduce the behavior you are seeing: this string works for me without the wildcard work-around.
I've seen a case where Navigator stores extra characters in Solr but doesn't display them in the UI. An API call with the UI displayed originalName doesn't return the entity. To check this, run the query that works (with the ugly work-around) and look at the value of the originalName in the output. Make sure that the string stored in Solr is exactly the string used in the API call. The case I saw where there is a difference, Navigator is storing the originalName with a "\n" newline character. In that case, I could not find a way to represent the originalName in the API call such that it matched what was in Solr. (I'll have to try with your asterisk work-around!) If there is a difference between what's stored in Solr and what's shown in the UI, it may be that we can construct a more specific string for the originalName that manages the extra character(s). Please check this out and let us know.
If it turns out that the originalName in Solr and the originalName string used in the API call are exactly the same, I would need your help to understand the problem more to know where to go next.
Do the originalNames for all operations behave like this or is it just this one? (again, what's in the string of the name: is it something that the source service is doing and Navigator isn't handling it well? That would be something we could potentially fix)
Can you reproduce the behavior using the Swagger UI for the API? (this would point to a syntax error or some sly issue with the manually produced call)
Do you get the same behavior using "queryText" instead of "originalName"? (I don't know if the source creates both strings the same way)
What is the goal? There another programatic way to accomplish your goals that doesn't require sending the operation name through an API call? Can you use the entity ID for example?