Hard crash on startup: 429 on GET /v1/me/ not covered by existing rate-limit retry handling

[luis-brea]

Describe the bug
On startup, spotatui sometimes fails immediately with a 429 error from
GET https://api.spotify.com/v1/me/ (the profile request made right
after loading the cached auth token). Unlike the Discover/startup 429
handling added in v0.36.0 (retries with Retry-After support, non-fatal
UI handling), this particular request seems to hard-fail the whole
startup instead of retrying or degrading gracefully.

To Reproduce

1. Have a working spotatui install with a cached auth token.
2. Run spotatui from PowerShell on Windows.
3. Sometimes (not always) it fails immediately with:
   Error: http error: status code 429 Too Many Requests
4. Relaunching a few times in a row seems to make it worse/more frequent.

Expected behavior
The /v1/me/ request on startup should retry (respecting Retry-After,
similar to the existing Discover/startup 429 handling) instead of
crashing the app outright.

Environment

• spotatui version: 0.41.0
• OS: Windows (PowerShell)
• Install method: official install script (curl -fsSL spotatui.com/install.sh | bash) run from PowerShell

Log excerpt
(token redacted)

​ [2026-09-02][15:07:38][spotatui::runtime][INFO] spotatui 0.41.0 starting up [2026-09-02][15:07:38][spotatui::runtime][INFO] audio backend initialized [2026-09-02][15:07:38][spotatui::runtime][INFO] panic hook configured [2026-09-02][15:07:38][spotatui::runtime][INFO] user config loaded successfully [2026-09-02][15:07:38][spotatui::runtime][INFO] client authentication config loaded [2026-09-02][15:07:38][spotatui::core::auth][INFO] authentication token loaded from cache [2026-09-02][15:07:38][rspotify_http::reqwest][INFO] Making request RequestBuilder { method: GET, url: Url { scheme: "https", ..., host: Some(Domain("api.spotify.com")), path: "/v1/me/", ... }, headers: {"authorization": "Bearer [REDACTED]"} } Error: http error: status code 429 Too Many Requests ​

Additional context
I tried the usual suspects first (--no-update, behavior.disable_auto_update: true,
behavior.enable_announcements: false) — none of these affected it, since the
429 is on the /v1/me/ profile call itself, not the update-check or
announcements requests.