You may have an old cached HSTS entry. But HSTS does not currently affect navigation. If you create a new Google Chrome profile you can see how it works without an HSTS cache.
The HSTS header has 2 modes: single domain and domain + all subdomains.
When applied directly to a domain (let's say example.com) HSTS forces all future connections to that exact domain to be made over https:. Say you access http://example.com and are redirected to https://example.com and the response from https://example.com does include the HSTS header but doesn't include the includeSubDomains setting. All future visits to example.com, until the HSTS header expires, will go immediately to https://example.com. It doesn't matter if you enter http://example.com in the Location bar — the browser takes you directly to https://example.com and you never encounter the http: → https: redirect again.
When applied to a domain and all of its subdomains, HSTS works as above except the policy is also enforced at all subdomains. So if I go to http://example.com, get redirected to https://example.com, and the https: response not only has the HSTS header but has includeSubDomains as well, then in the future if I go to http://click.example.com (which I've never actually visited before) the browser won't even try to take me there. It'll attempt to open https://click.example.com immediately, because the includeSubDomains is remembered from before. In case click.example.com doesn't even support SSL (it has no cert) or it has a non-matching cert name, then the request will fail. Having a long-expiring HSTS policy that has includeSubDomains but isn't adequately tested on all known subdomains can thus be catastrophic, because everyone who hits the site will try to connect to possibly broken sites and you can't make them all clear their caches!
But the current navigation path doesn't include an HSTS header that would affect the click tracking domain.
.png)