ResponseEntity has a dedicated method ResponseEntity.of(ProblemDetail), which uses the status property of ProblemDetail and returns a builder to add headers, or one can also return just ProblemDetail, if there is no need to add headers. However, if ResponseEntity wraps a ProblemDetail as any other body, i.e. not using the dedicated method, and the status from the ResponseEntity which actually sets the response, could be mismatched with the one listed in the body.
One option would be to reject this, but than a 500 error would obscure the original problem, and would only be discovered at runtim. In that sense, it might be better for the client to get a response with the status from the ResponseEntity, even if the body details, which should be informational, don't agree.
Perhaps the best middle ground would be to log a warning to ensure this is noticed proactively, while the client still has a better chance of handling the response than they would with a 500.