... and they are making me confused, so for a quick yes/no question.
Unfortunately the answer is not a simply yes/no. Instead it depends on the specific setup of client and proxy. While in all cases there will be encrypted traffic between client and proxy and proxy and server it differs on how much visibility the proxy has into the traffic and how much visibility an attacker between client and proxy has.
https:// site is accessed using a classic HTTP proxy the client will issue a CONNECT request to the proxy and ask the proxy to create a tunnel to the final server. This tunnel is then used to exchange the end-to-end encrypted HTTPS traffic between client and server. This is thus a client-to-server encrypted traffic, not a client-to-proxy encrypted and then (with new keys) proxy-to-server. The proxy can only see the already encrypted traffic and has no visibility into the decrypted traffic.
But, there are HTTPS intercepting proxies, which don't just forward the encrypted traffic. Instead they terminate the HTTPS traffic at the proxy and create a new HTTPS connection to the server. This means there is an encrypted connection between client and proxy and another encrypted connection between proxy and server and the proxy has full visibility of the decrypted traffic. This setup requires though that the proxy can dynamically create certificates matching the server and that the client trusts these newly create certificates, by trusting the issuing CA at the proxy. This is the kind of setup used for example in corporate proxies. It is also possible to do this with squid.
There is also a way that there is an additional encryption between client and proxy. This is the case if when the proxy itself is accessed by
https:// (i.e. not only the server). It works like the normal HTTP proxy, only that the connection from the client to the proxy is also HTTPS. Which means that access to the HTTPS site is doubly encrypted between client and proxy and the proxy removes the first encrypted layer but forwards the inner traffic directly to the server. The common use case for this is an external proxy, where the connection to the proxy itself is unsafe and should be protected against sniffing and manipulation. Otherwise an attacker could for example sniff the target given in the CONNECT request or might even modify the given target. This kind of setup is not supported by all HTTP clients, but it is supported by modern browsers and also by squid - see Encrypted browser connection.
To add to the confusion: encrypted browser connection might also be combined with HTTPS interception.