Asterisk: I don't have the answer to the question. I was able to reproduce the OP's scenario and I am just having a stab at what
might be happening.
I started with some basic digging into how certificates are validated by browsers. It looks like when a site serves an SSL cert and the top of the certification path is not a root CA in the trust store, other mechanisms seem to be kicking in. Server-based Certificate Validation Protocol (SCVP) seems to be a mechanism to bridge this "gap" in the trust chain. The wikipedia article on SCVP seems to say the following -
CAPI is capable of building certification paths using any certificates that are installed in Windows certificate stores or provided by the relying party application. The Equifax CA certificate, for example, comes installed in Windows as a trusted certificate. If CAPI knows about the ACME Co CA certificate or if it is included in a signed email and made available to CAPI by Outlook, CAPI can create the certification path above. However, if CAPI cannot find the ACME Co CA certificate, it has no way to verify that Joe User is trusted.
SCVP provides us with a standards-based client-server protocol for solving this problem using Delegated Path Discovery, or DPD. When using DPD, a relying party asks a server for a certification path that meets its needs.
Note: CAPI stands for Cryptographic Application Programming Interface. More details in the Wiki article.
My stab in the dark: Chrome is using SCVP (or similar) to validate the certificate when the root cert is no longer present in the Windows cert store. Now, there is a possibility that I am wrong and SCVP is purely for certificate revocation mechanisms like OCSP, but i thought not simply because Chrome disabled OSCP in 2012 and probably doesn't use SCVP for revocation checks.