Getty client read timeout should remove half-dead session from pool

## Describe the bug

On the Dubbo/Getty consumer side, when `session.WritePkg` succeeds but `response.Done` never fires, `Client.Request` returns `errClientReadTimeout` **without** removing the session from the connection pool.

`selectSession()` still randomly picks that half-dead TCP connection for later requests, so a single bad session can cause repeated ~request-timeout failures (often clustered on one consumer pod) until heartbeat eventually removes it (typically after multiple missed heartbeats).

This was observed in production: consumer-side read timeout while the provider RPC completed quickly (`cost=0ms SUCCESS`), consistent with a half-dead / stuck connection rather than a slow business handler.

## Expected behavior

On client read timeout for a two-way request:

1. Immediately `RemovePendingResponse` for the request ID (avoid late response matching a stale waiter)
2. `removeSession` + `Close` the session used for that request (do **not** close the whole `Client`)
3. Prefer skipping already-`IsClosed()` sessions in `selectSession`

## Related

- `remoting/getty/getty_client.go` `Request()` timeout branch currently only returns the error
- `RemovePendingResponse` is already exported (see #3440); timeout path should call it and drop the session

## Proposal

Patch `Request()` timeout path + skip closed sessions in `selectSession()`, with an integration-style test that blocks the provider longer than the client timeout and asserts the session is removed from the pool.