Stage-1: Auth storage v2 and token resolution (no UX change)

[l2ysho]

Note

TL;DR — The auth layer holds one account and cannot tell where a token came from. Three resolvers disagree about which token wins, auth.json is a flat blob for a single user, and the keyring uses one fixed name per secret. This stage rewrites all three so the storage can hold N accounts. Nothing changes for users — no new flags, no new commands. Three subtasks, each releasable on its own.

Part of #1297. Comes after Stage-0 (#1387), and everything later depends on it.

Subtasks

#	Issue	What
1	#1418	Token resolution — one resolver, one precedence order, only login persists
2	#1419	auth.json v2 — profiles keyed by user ID, with migration
3	#1420	Secret storage v2 — per-profile keys in the keyring and the file backend

Order is fixed. 2 needs 1's read/write split; 3 needs the user IDs from 2.

Decisions already made

• Precedence is --token → APIFY_TOKEN → stored. It is what mcp install and the actor entrypoint already do; only resolveToken differs.
• APIFY_TOKEN keeps working. Removing it would break CI, agent harnesses and every Actor run.
• apify login ignores APIFY_TOKEN. Logging in is explicit.
• Only apify login writes credentials. --token and APIFY_TOKEN are one-off.
• Profiles are keyed by userId, not by a display name, so a rename cannot orphan a secret.
• The XDG config directory move is not part of this. Nobody outside Apify has asked, and two migrations in one release is how you get a bug nobody can reproduce.

Not in scope

No additive login, no --profile, no auth switch, no auth list. The file can hold N profiles; only Stage-2 (#1386) puts a second one there. Users see no difference after this stage.

Compatibility

After #1419 an older CLI reads the new file, finds no token, and reports that you are logged out. Needs a changelog note. The auth.json.v1.bak written by the migration is the manual way back.

🤖 Generated with Claude Code

[patrikbraborec]

Folding #567 in here. Its proposal: replace the flat auth.json with a keyed structure (Record<UserId, Data> or an array of entries) that holds 0..n accounts, and store only what the CLI needs (token mandatory, username maybe, profile/email/plan fetched on demand). Per @vladfrangu it must be adapted to the keyring setup.