Store a per-profile API URL for multi-environment auth

[514sid]

Background

The multi-profile auth work in #293 stores only a token per profile, and every command resolves the API host from the single API_BASE_URL (defaulting to prod). Since multi-profile usually means multi-environment (for example a prod profile and a stage profile), this means:

• auth list sends every stored token to the one host, so a stage token gets transmitted to the prod host and then shows blank because it 401s.
• There is no way to keep a profile pinned to the environment its token belongs to.

Raised by @sergey-borovkov in review: it is much cheaper to decide the storage format now, while it is new, than to migrate it a second time later.

Proposal

Store an optional API URL per profile and use it wherever a profile's token is used (read_token/Authentication::new, fetch_profile_info, fetch_profiles_with_info). Profiles without a URL (including migrated legacy ones) fall back to the current global default, so this stays backward compatible.

Open decision — how is the URL captured?

This is the reason it was deferred from #293 rather than guessed at. Options:

1. screenly login --url <url> — explicit, but one more flag to pass.
2. Capture the resolved API_BASE_URL (env or default) at login time and store it — zero new flags, but implicit and easy to get wrong if the env var isn't set.
3. Both: --url overrides, otherwise capture the resolved base URL.

Option 3 is probably the most forgiving. Worth agreeing on before implementing.

Scope / touch points

• TokenStore schema: each entry becomes token + optional url (migration-safe, since serde Option defaults to None).
• Migration: legacy plain-text and existing single-token stores get url: None → global default.
• read_token / Authentication::new: resolve the active profile's url alongside its token.
• fetch_profile_info / fetch_profiles_with_info: use the per-profile url.
• Tests: per-profile url round-trips, fallback to default when absent, auth list hits each profile's own host.

Notes

• Not a blocker for Add multi-profile authentication support #293; that PR intentionally leaves this out.
• Backward compatible if the url field is optional with a default.