me / accounts list under an agent's BASECAMP_TOKEN fail with a misleading 'invalid or expired token' #972

🤖 Drafted by an agent for @jeremy, from running basecamp-cli inside agent-sandbox-nono.

What happens. When BASECAMP_TOKEN holds an agent's token, basecamp me (and accounts list) ask Launchpad's /authorization.json. Launchpad refuses agent self-tokens, so the result is:

"error": "Authorization failed: invalid or expired token",
"hint": "BASECAMP_TOKEN is set and every request uses it instead of a stored login; unset it, or export a token the server accepts"

The token is fine: the same token gets 200 from GET /<account>/my/profile.json, and basecamp people show me answers with it.

Why. agentProfile() (internal/commands/people.go) already routes me through /my/profile.json for a stored agent credential ("an agent's self-token has no identity behind it, so /authorization.json refuses it"). It returns false whenever BASECAMP_TOKEN is set, since the env token's type is unknown. The hint in internal/appctx/context.go then tells the person to unset a token that works.

Where it bites. agent-sandbox-nono gives its sandboxed agents Basecamp access through BASECAMP_TOKEN, holding the agent's token, with the account pinned. An agent that runs basecamp me to orient itself is told its token is invalid or expired. The sandbox now refuses me and accounts list by name and points to people show me, but the CLI is where this should be fixed.

Suggested.

1. When /authorization.json answers 401 under BASECAMP_TOKEN and an account is known (--account, BASECAMP_ACCOUNT_ID, or config), fall back to /my/profile.json for me, as agentProfile already does.
   Alternatively, accept an explicit hint that the env token is an agent's (for example BASECAMP_TOKEN_TYPE=agent).
2. Don't advise unsetting a token that the API accepts. For example: "Launchpad didn't accept this token (agent tokens have no Launchpad identity): basecamp people show me shows who it is".