fix(cli): correct the login token URL, and name the real cause of edge 401s

[albertcmiller1]

Three bugs surfaced while confirming that PATs don't authenticate against deployed backends.

1. yertle login printed a URL that 401s

It appended /settings to the API base URL. Tokens are minted in the web app:

https://api.dev.yertle.com/settings (what login printed)	401
https://dev.yertle.com/settings (where the page is)	200

Every first-time user was sent to a 401 page during their first interaction with the tool. It's been wrong since the command was written.

_web_url_for() now derives the web host, and declines to guess rather than being confidently wrong:

https://api.dev.yertle.com   -> https://dev.yertle.com/settings
https://api.yertle.com       -> https://yertle.com/settings
http://localhost:8000        -> http://localhost:3000/settings
https://weird.internal       -> "…from the Settings page of your Yertle web app"

--web-url overrides it.

2. The 401 message named three causes, none of them the real one

Deployed hosts sit behind API Gateway's Cognito JWT authorizer. A yrt_ PAT isn't a JWT, so it's rejected structurally, before Lambda runs and before any lookup — the www-authenticate header says error_description="token contains an invalid number of segments". Telling users their token might be "revoked or expired" sends them off to debug a token that is perfectly valid. (I watched exactly that happen.)

Before / after against api.dev.yertle.com with a freshly minted PAT:

- 401 Unauthorized — token rejected by the backend. Likely causes: the token was
-   issued by a different backend..., the token was revoked, or it has expired.

+ 401 Unauthorized — rejected before reaching the Yertle backend.
+   This host sits behind a JWT authorizer that does not accept personal access tokens:
+   a `yrt_` token isn't a JWT, so it's refused on sight and never looked up.
+   Your token is almost certainly fine — PATs currently work only against a
+   locally-run backend.

UnexpectedStatus exposes only status_code and content — no headers — so detection keys off the body shape: API Gateway returns {"message": …}, FastAPI returns {"detail": …}. That's precisely the difference observed between dev and localhost. App-level 401s keep the original message, verified against a real bad token on localhost.

3. login accepted an empty token

It would persist {"token": ""} — a config that looks populated but resolves as unauthenticated, since resolve() treats "" as absent. Now refuses and saves nothing.

Found by nearly clobbering my own config while testing (1).

Testing

make check green (93 tests, +12). All twelve new tests verified to fail against the previous implementation. Both messages checked against live backends — dev for the edge rejection, localhost for the app-level one.

Note

This makes the failure legible; it does not fix it. PATs still cannot authenticate against any deployed environment — that's the infrastructure gap, tracked separately.

🤖 Generated with Claude Code