Multi-token / multi-account handling in the CLI #1297

Problem

The CLI holds a single API token at a time (one account), stored in auth.json and the OS keyring. Switching accounts or organizations means running apify logout then apify login again; there is no way to keep multiple tokens registered or switch between them.

Goal

Let the CLI store multiple accounts under named profiles and switch the active one without re-authenticating. Commands run against the selected account.

Open questions

• Profile model, and how the active profile is selected (default profile?). -> Stage-3
• Selection surface: a per-command --account flag, an apify auth use <name> command, an env var, or a mix. -> Stage-3
• Storage: extend auth.json and the keyring to hold multiple entries. -> Stage-1
• Backward compatibility with existing apify login and logout. -> Stage-1 or Stage-3

Plan

Stage-0: Verify test and coverage #1387

Audit the auth test coverage before we start moving code. Fill only the gaps that protect
code we are keeping.

Known gaps to confirm:

• getLoggedClient writes the keyring token, the proxy password and auth.json on every
  command; none of that is asserted
• logout has one test and checks the exit code only — nothing verifies the secret is gone
• resolveToken has no tests, so current APIFY_TOKEN behaviour is not pinned
• proxy password reaching the apify run child env is untested
• the bundle keyring path (__APIFY_KEYRING_NATIVE_SUBPACKAGE__) has no smoke test

Stage-1: Auth storage v2 and token resolution #1383

Rewrite the auth layer so it can hold more than one account. No user-visible change — no new
flags, no new commands. Each subtask is releasable on its own, in this order:

• Token resolution Token resolution #1418 — one resolver instead of three. Precedence --token →
  APIFY_TOKEN → stored, and only apify login writes credentials
• auth.json v2 auth.json v2 #1419 — profiles keyed by user ID, field trim, migration of the three
  states in the wild
• Secret storage v2 Secret storage v2 #1420 — per-profile keys in the keyring and in the file backend

Closes #567. Supersedes #1293 and #1246, and closes #720.

Compatibility: after #1419 an older CLI reads the new file, finds no token and reports that
you are logged out. Changelog note needed; the migration writes auth.json.v1.bak.

Stage-2: Login - token multi account support #1386

Make apify login additive, so a second account can be stored at all.

• login adds or updates a profile keyed by user ID; the new account becomes active
• the profile name comes from the token, the username from user('me')
• logout acts on the active profile, then switches to the most recently used one that remains
• a user with a single account sees no change

Selecting between accounts is Stage-3, so until then a second account is reachable only by
logging in to it again. The Console browser flow inherits the additive behaviour but gets no
work — the device flow in #1328 replaces it.

Stage-3: Multi-account UX #1384

The first stage users see. Adds the way to pick an account.

• --profile <name|userId> on commands that hit the API, injected by the framework the way
  --json is
• apify auth switch [name] and apify auth list (with --json, no network calls)
• apify logout --profile <name> and --all
• auth failures name the profile, so a 401 means re-authenticate that profile (actors search fails with 401 when user has expired/invalid token #1051)

APIFY_TOKEN still wins over everything, so --profile or auth switch together with it is an
error rather than a silent override. auth list, auth token and logout keep working.

Not here: renaming profiles, APIFY_PROFILE, an actor.json pin, and any change to
mcp install.