Improve spt update token fallback handling

[mikehorgan-dell]

Summary

Reworks how spt update applies GitHub tokens so a stale ambient token no longer breaks public-repo update checks, while deliberate --token usage still fails clearly.

Background: a user hit 401 Unauthorized: Bad credentials running spt update against the public repo because a stale GITHUB_TOKEN / SPT_GITHUB_TOKEN (or dotenv value) was eagerly sent. Public release lookup does not require auth.

Behavior

• Explicit --token authenticates from the first request and fails clearly if invalid (no silent ignore even when unauthenticated would have worked).
• Ambient env/dotenv tokens are best-effort: release lookup is attempted unauthenticated first, and the token is only used to retry on a rate-limit response.
• A bad ambient token no longer triggers a doomed unauthenticated retry: the original rate-limit error is surfaced and a targeted warning names the offending source.
• Rate-limit detection now covers secondary/abuse limits (403 + Retry-After), not just primary (X-RateLimit-Remaining: 0).
• Each release-list attempt gets its own network timeout budget instead of sharing one deadline across sequential calls.

Conscious trade-off

For private repos, an ambient token is only exercised on the rate-limit retry; explicit --token remains the supported private-repo path. This matches the stated public-repo scope and is documented in the planning notes.