Traefik Mesh timeout propagation and connection pooling behavior

In a Traefik Mesh environment, request lifecycles are managed via sidecar proxies using Transport resources. While these resources allow for granular control over handshake and response body durations, there is ambiguity regarding how the mesh handles the underlying connection when a mesh-level timeout is triggered.

When a timeout defined in the Traefik Mesh configuration is reached, the sidecar terminates the request. However, it is unclear whether this termination immediately returns the connection to the pool or leaves the connection in a stale state until a socket timeout occurs. This is particularly relevant when application-level socket timeouts differ from mesh-defined settings.

How does Traefik Mesh manage the state of pooled connections after a Transport-level timeout occurs? Is there a mechanism to ensure that the backend service receives a cancellation signal before the sidecar closes the socket?