gitproto: refuse cross-host helper-auth retry when TLS verification is off

Closes the SkipTLSVerify × redirecting-endpoint × credential-helper interaction: with cert validation disabled, the post-redirect host could be a MITM presenting any self-signed cert for the host the helper would Lookup creds against. Sending the user's stored credentials there is exactly the leak the rest of the redirect-aware fix was designed to prevent — so when InsecureSkipTLSVerify is on we bail out of the cross-host paths before any helper traffic happens and let the 401 surface.

Specifically:

• tryHelperRetry: when the 401 came from a host different from c.EndpointURL.Host and InsecureSkipTLSVerify is true, return res as-is (no Lookup, no retry, no Approve/Reject).
• EnsureAuthForService: same gate after the anonymous probe. Anonymous probes are still allowed to follow the redirect (no creds to leak), but the 401 doesn't lead to attaching anything.
• Same-host 401s are unaffected: the user already accepted that host when they configured the sync, so SkipTLSVerify being on doesn't introduce new exposure on the retry there.

New HTTPConn.InsecureSkipTLSVerify field; syncer plumbs raw.SkipTLSVerify into it whenever the connection is built (mirroring how it's already plumbed into the HTTP transport).

Tests:

• TestRequestInfoRefs_CrossHostRedirectWithSkipTLSVerifyRefusesTo- SendCreds — asserts 0 Lookup/Approve/Reject calls, no Authorization header on any RoundTrip, c.EndpointURL unchanged, and the 401 surfaces to the caller.
• TestRequestInfoRefs_SameHostUnauthorizedWithSkipTLSVerifyStill- Retries — the gate is targeted: same-host retries still work with TLS verification off.
• TestEnsureAuthForService_CrossHostProbeWithSkipTLSVerifyDoesNot- Attach — EnsureAuthForService variant.