Send GitLab the right auth on the right host

[ppXD]

Summary

• Send each GitLab call the one credential header its type names (PRIVATE-TOKEN for personal, project and group access tokens, Authorization: Bearer for OAuth, never both), through NGitLab (GitLabRequestOptions) and every raw call (GitLabHttp). Behind a redirecting base URL a PAT used to work and an OAuth token read 401, and GitLab 13.0 to 17.7 refused a 41+ character access token sent as a Bearer.
• Follow a redirect only inside one origin, with the credential attached again. A redirect to another scheme, host or port, and the next page of a list whose Link: rel="next" names another origin, are refused before any credential is attached and fail with the typed provider_base_url_redirects, naming the URL. NGitLab never re-sends a write; a raw write is repeated only by a 307 or 308, and a 301, 302 or 303 that would turn it into a GET is refused instead of being read as the write's answer (OriginScopedRedirectHandler.RepeatsWritesOnly, opt-in).
• A tokened git clone, ls-remote or push whose remote sends git to another origin now fails naming that redirect (same code, with the origin git was sent to) instead of git's could not read Username prompt. It remains a WorkspaceException, so existing catch sites behave as before.
• Adding a provider or moving its API address probes GET /api/v4/version once, with no credential, and refuses an address that redirects to another origin. An edit that leaves the address as stored asks nothing; no stored base URL is ever rewritten.
• An edit that only upgrades http to https on the same host (80 to 443, or one explicit port) is no longer a move past connected tokens, so a redirecting base URL can be fixed without disconnecting every member. While tokens are connected the new address must also answer HTTP (any status); otherwise the edit is refused with provider_endpoint_unreachable and the stored address stays, because undoing a mistaken upgrade would itself be a refused move. With no token connected nothing is asked.
• Resolving a credentialed GitLab clone logs a Warning when the clone URL's origin differs from the base URL's. Nothing is rewritten.

Behaviour to review: an instance whose GitLab emits Link headers naming a different origin than its stored base URL (a misconfigured external_url or proxy) previously had paged NGitLab reads follow that link with the token. Those reads now fail with provider_base_url_redirects naming the origin; editing the base URL to it (an http to https upgrade is allowed while tokens are connected) fixes it.

Test plan

• Unit: header selector, redirect handler origin and write rules, paging link and raw-write matrices (http to https, host alias, other port) for PAT and OAuth, git redirect parsing and WorkspaceException mapping, probe answer check (any status, redirect, TLS to a plain port, down, silent, cancel), failure code pins (full unit suite 14094 passed)
• Integration: real git clone, push and integrate through a remote that redirects to another authority name the redirect and send no credential; same-authority redirect still works; carve-out accepted only where the new address answers, not asked with no token bound
• E2E: provider add refused when its address redirects; an https upgrade past a connected token is refused with provider_endpoint_unreachable while the token keeps working at the stored address (full E2E project green)
• Staging: edit a redirecting GitLab base URL from http to https with a connected token and confirm repository reads and a clone succeed
• Staging: confirm no existing instance logs provider_base_url_redirects on paged reads after deploy