Beware of terminology. Certificates relate to asymmetric cryptography in which keys go in pairs: each pair contains a public key and a private key, which are two facets of the same underlying mathematical object (which depends on the algorithm type). Crucially, the private key cannot be computed from the public key, which is exactly why the public key can be made public.
The certificate contains the public key -- only the public key. When a SSL client connects to a SSL server, the server sends its certificate to the client, but certainly not the corresponding private key. Instead, the server uses its private key to perform an operation that only the server can do (because that operation requires the private key and the private key is private).
Similarly, when a SSL client connects to a SSL server and the server asks for a "client certificate", it really means that the client will send its own certificate (with the client public key) and will demonstrate its mastery of the corresponding private key by performing an operation that can only be done with the private key (but can be verified with the public key); this is a signature.
In your envisioned scenario, a client C connects to a first server S1, and S1 sends to C a copy of its certificate. Then C connects to a second server S2 that asks for a "client certificate". C may send the certificate that it received from S1, but that won't go far because C does not have access to the corresponding private key: that key never left server S1, the client does not have any access to it. Thus, C won't be able to complete the authentication with server S2.
The exact extra markings in the certificate (client auth, server auth...) are merely supplementary restrictions on certificate usage, but they are not the foundation of the cryptographic security here. What matters is that a certificate contains only a public key, not the corresponding private key.