It seems like your security team has an overly-strict idea of what Content Spoofing is. For a background, I'm looking at the OWASP page on Content Spoofing, main point:
When an application does not properly handle user-supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user. This presents the user with a modified page under the context of the trusted domain.
As usual, ask your security team for a demo of the vulnerability that they believe they have found! If they believe there is a Content Spoofing / Cross-Site Scripting (XSS) vuln here, then they should be able to demonstrate it (ie craft a request to your server that results in a <script>alert()</script> popup in your browser.
Content Spoofing attacks (and XSS more generally) are all about sending malicious input in the request that is reflected in the response.
The point of the Content-Type: header is to tell the browser how to interpret the response. This can help reduce the attack surface because you only need to worry about user input that is malicious within the specified content type. For example, if it's Content-Type: text/html then you need to HTML-escape any user-supplied text that has been embedded in the response. If it's Content-Type: text/javascript, then I really hope you're serving a static .js file and not reflecting any user input into it. On the flip side, if its Content-Type: text/text or Content-Type: application/json than you don't need additional output escaping because the browser won't try to run this as code anyway.
Your situation
It sounds like you have an API endpoint that accepts POSTs with a JSON body, and on errors it returns an HTML error page. I agree that it's more common for JSON APIs to return JSON error messages, but returning static HTML error pages is perfectly fine from a security perspective. Of course, if you're taking parts of the request and embedding them un-escaped in the HTML response, then you'll have XSS, but that's almost a separate issue.
From reading your question, it seems like your security team wants the attacker to be able to control the Content-Type of the response? That seems absurd to me. The Content-Type header should match the content; if the error response contains an HTML page, then the server should indicate so with Content-Type: text/html.
As stated above, if your security team believes there is a security issue here, then ask them to demo it!
