Fix unicode unescape behavior affected by sequential replace

[chage]

I believe there is an issue in the unicode unescape logic.

The current implementation performs two replace operations sequentially, where the second replacement may be affected by the result of the first one. This can lead to incorrect behavior in certain cases.

I'm not sure whether this behavior was intentional. Looking through the commit history, it appears the implementation has been this way since it was introduced, and I couldn't find additional context explaining the design choice.

To clarify the problem, I added a test case that demonstrates the issue.

Please see the new test for a concrete example of the behavior.

[hlship]

Thanks for the patch; did you find this in the wild? That an awful lot of escaping and unescaping!

[chage]

Yes. We use a JSON scalar type in a query field, and one day someone submitted some unusual data. 😅