OAuth login and token refresh refused when DNS returns fake-IP addresses (198.18.0.0/15), with no supported way to trust them #849

Since v0.10.0 (#656), OAuth requests go through oauth.DefaultIssuerPolicy, which refuses 198.18.0.0/15. Some networks use fake-IP DNS with transparent routing: every hostname resolves to a 198.18.x address and the connection is carried to the real host with end-to-end TLS. On those networks both the login code exchange and token refresh are refused. v0.9.1 works on the same machine. One common source is mihomo (Clash Meta), whose default fake-ip-range is 198.18.0.1/16 when fake-ip mode is on.

It's easy to miss. API calls made with a valid token aren't checked, so a machine upgraded to 0.10.0+ keeps working until its first token refresh, which can be days or weeks later. After that it can't refresh or log in again.

Repro (seen on 0.11.0; Debian 13, Linux 6.12, x86_64):

$ getent ahosts launchpad.37signals.com
198.18.0.1      STREAM launchpad.37signals.com
$ getent ahosts app.basecamp.com
198.18.0.1      STREAM app.basecamp.com

$ basecamp auth refresh
{
  "ok": false,
  "error": "token refresh failed: token endpoint \"https://app.basecamp.com/oauth/tokens\" resolves to an address refused by the address policy (see oauth.DefaultIssuerPolicy)",
  "code": "api_error",
  "retryable": false
}

$ basecamp auth login --remote
warning: OAuth discovery failed for https://3.basecampapi.com, using Launchpad fallback
...
Paste the callback URL:
{
  "ok": false,
  "error": "token exchange failed: token endpoint \"https://launchpad.37signals.com/authorization/token\" resolves to an address refused by the address policy (see oauth.DefaultIssuerPolicy)",
  "code": "api_error",
  "retryable": false
}

On the same machine, basecamp auth refresh on v0.9.1 succeeds.

Why existing options don't cover it. BASECAMP_OAUTH_USE_PROXY=1 only applies when HTTP(S)_PROXY names a proxy. With transparent routing nothing is set, so requests stay on the guarded direct transport. No setting trusts a resolver or address range, and surfguard's Allow() can't re-admit IANA special-use prefixes. Checked against main at 8663bda (basecamp-sdk v0.23.0).

Ask: a supported opt-in, such as an env var or config setting, that trusts a given CIDR only for the built-in Basecamp and Launchpad endpoints, with TLS certificate verification still required. Discovered or custom endpoints would keep the strict policy, so this doesn't weaken the SSRF protection for anything a server response names.