Address review: allow http→https upgrades, anchor the guard per request

Two findings from nodo, both confirmed by direct check, and both false negatives — credentials withheld where they should not be, so they break working configurations rather than leaking anything.

sameSite required an exact scheme match, so an http endpoint redirecting to https on the same host read as cross-site. GitHub does this, as does most every reverse proxy, and it works today because the stdlib carries Authorization when only the scheme changed. The result would have been a hard 401 on a working config, with the documented "store it in the credential helper" remedy inapplicable because the host never changed. The stated goal was only to stop a downgrade putting a credential on the wire in plaintext, so the upgrade direction is now allowed and the downgrade still is not. The credential was already reaching that host in the clear, so an upgrade strictly improves matters.

guardRedirects closed over EndpointURL at construction, but a connection's effective endpoint moves: setResolvedEndpoint adopts a redirect host, and helper credentials are then looked up for that host. Any further hop that never left the adopted host still failed sameSite(EndpointURL, ...) and lost its Authorization — undercutting exactly the path the withheld-credentials warning sends people down. The guard now anchors on via[0].URL, the URL the redirect chain started from, which is accurate per request for both the token case and the helper-retry case, and lets the closure drop the captured endpoint entirely. A nil anchor still fails closed.

Both are covered by tests, and the anchor test was confirmed to fail against the construction-time version. docs/usage.md and the changelog described an exact scheme match and now describe the downgrade rule.