fix(auth): recognize API keys and bearer token in 'pup auth status'

[platinummonkey]

Summary

pup auth status only inspected OAuth2 token storage. When a user authenticated via DD_API_KEY+DD_APP_KEY (or DD_ACCESS_TOKEN), the command reported ❌ Not authenticated even though every other command worked — confusing agents that wrap pup into thinking auth was broken.

Status now reports the credentials it actually finds, matching the auth headers the client puts on the wire.

Changes

• src/commands/auth.rs — extract build_non_oauth_status() for the no-OAuth-tokens arm of status(). The helper delegates auth-type detection to client::get_auth_type so this command can never disagree with the client about which credentials are in use.
• The JSON output gains an auth_method field (bearer_token / api_keys) on the two new authenticated branches; the unauthenticated payload is unchanged for backward compatibility.

Behavior

Before, with DD_API_KEY/DD_APP_KEY set:

❌ Not authenticated for site: datadoghq.com
{ "authenticated": false, "status": "no token", ... }

After:

✅ Authenticated for site: datadoghq.com (DD_API_KEY + DD_APP_KEY)
{ "authenticated": true, "auth_method": "api_keys", "status": "valid", ... }

Testing

• 6 new unit tests cover every branch of build_non_oauth_status, including bearer-takes-precedence-over-api-keys (matches client::get_auth_type) and partial-key (lone DD_API_KEY) rejection.
• 2 new tokio::test integration tests cover the status() wiring on the api-key and bearer paths.
• All 39 commands::auth tests pass; cargo fmt --check and cargo clippy --all-targets -- -D warnings are clean.

Test plan

• cargo test --bin pup commands::auth
• Manually run pup auth status with only DD_API_KEY+DD_APP_KEY set and confirm authenticated output
• Manually run pup auth status with only DD_ACCESS_TOKEN set and confirm authenticated output
• Confirm pup auth status after pup auth login still shows OAuth token details unchanged

🤖 Generated with Claude Code