1) If the intermediate certificate (B) is trusted - that is, it is a valid signing certificate, not expired, not tampered with, and not revoked - then it being in the trust store is enough that the TLS client doesn't need to continue up the chain in order to verify the leaf certificate.
However, that "not tampered with" thing requires having a trusted certificate have signed the intermediate certificate. Now, the intermediate cert could be self-signed, just like the root certs are, in in addition to being part of a chain up to the root certs. In that case (assuming the signature checks out), there's no need to verify the chain above the intermediate cert.
Some clients may not even bother verifying that the certificate has a valid signature on it (it's in the trust store, so it's trustworthy, in theory) or that it hasn't been revoked (a lot of older browser didn't check for revocation by default, assuming they'd be updated with an updated list of revoked certs no longer being in the trust store instead). In practice, though, you should assume both these things (valid signature even if it's self-signed, and not revoked) are checked by most clients.
2) That depends entirely on the server. It's typical to serve everything except the root cert, but some servers send the entire chain. If you use a site like Qualys SSLLabs, it'll show you the certificates that the server sends. This site appears to send two certs - a wildcard leaf for
*.stackexchange.com and a "Server CA" intermediate, but not the root cert (which is a DigiCert EV root CA, and signed the intermediate cert). However, some other sites do send the full chain; SSLLabs will flag it if you do so, but usually it's just kind of wasteful.