JSON API response flagged as XSS by vulnerability scanner. Is this a false positive?

An XSS vulnerability usually consists of two components: A backend which reflects user-provided strings without filtering them and a frontend which puts that input into a HTML document without filtering it.

So you don't just need to look at what the server does, you also need to look at the application which consumes that JSON response.

Is there a possibility that it will inject the path into a HTML document as-is without escaping any HTML tags in it first? Or that it processes that JSON document not with JSON.parse but with eval which would allow the server to pass exectuable code to it?

If that's the case, then the first priority would be to fix the consuming application. But as part of a defense-in-depth strategy you would also be well-advised from preventing the server from passing strings which contain valid HTML to the client. A good approach is to encode < and > as < and >.

Also make sure that the JSON response doesn't get malformed if the user-provided string contains a ". That might not just be annoying, it could also be abused in some scenarios to confuse the tools which consume the response.

This isn't vulnerable to XSS since the Content-Type is set to application/json and thus no Javascript will be executed by all major modern browsers. If you do some fancy Javascript stuff with the JSON response, it could become a DOM XSS (but this doesn't seem to be the case here from what you shared).

A more detailed answer can be found here.

This looks like a finding that many automated scanners will find: they put something in the URL and see it reflected back in the response body.

In your case, this is reported back in valid JSON and therefor this is not an issue. While not clean as a whistle, you'll be hard pressed to find a browser or API consumer that fails on the text in there. For all you know, that dangerous looking HTML could be valid and it's up to the client to deal with that well.

Not so much in a text/html context, there's a case for this in that scenario.