Retry over new TCP connection lets stale request land after ack

When an RPC client times out and resends on a new connection, the original copy can still be in the network, unread in a half-open server socket, queued, or mid-execution in a worker, and land after the retry was acked and after later calls (an acked write gets reverted, mkdir reappears after rmdir, unlink deletes a re-created file). Idempotency doesn't fix this, because the problem is ordering against later calls, not double execution. Fix: tag each connection with a client id, close that client's older connections and drop their queued requests on reconnect, and hold the new connection's requests until no old-connection request is still running. A spec clause like 'timed-out calls are concurrent with all future ops' must apply to the call, not to each copy, or it licenses these stray copies. You can only observe a violation via a later conflicting op (overlapping write, size change, inverse namespace op), or via mtime.