Drop the v1 auth.json and unkeyed keyring migration paths #1480

Context

Raised in #1459 review. Stage-1 (#1383) moved auth to v2: profiles keyed by user ID, secrets keyed per profile. To keep old installs working, the CLI still carries v1 code:

• Top-level token and proxy on AuthFile, plus LegacyAuthFile — auth-file.ts#L40-L57
• v1 → v2 file migration (toV2, MIGRATION_STEPS) — auth-file.ts#L123-L153
• Pre-migration read path — auth-file.ts#L222-L225
• Fixed-name keyring entries (legacyKeyringKey) and the code that moves them — credentials.ts#L44, ensureMigrated #L311, dropUnkeyedSecrets #L346, keyKeyringSecrets #L361, ensureSecretsKeyed #L424

Proposal (from the thread)

• Watch the users-per-version telemetry dashboard. Remove the v1 code when 90–95% of users run a version that includes the migration. About 5% of users stay on old versions (some on deprecated Node), so 100% is not a realistic target.
• Announce the removal before it ships (changelog, release notes), so users who skip the window know to run apify login again.
• After removal, a user with a v1 file is logged out and must log in again. login and logout must still wipe v1 entries from auth.json and the keyring, so no plaintext secret stays behind.

Open questions

• Q1: Remove at all, or keep the migration forever? Cost of keeping: the extra types, keyring reads on migration, and test surface. Cost of removing: a forced re-login for late upgraders.
• Q2: Which version counts as "migrated" — the first release with auth.json v2 #1419/Secret storage v2 #1420, or a later one?
• Q3: Should logout keep the legacyKeyringKey cleanup after the rest goes, as a cheap safety net?

Done when

• Threshold and target release agreed
• Deprecation announced
• v1 types, migration steps, and legacy keyring paths removed; tests updated
• login/logout still clear any v1 leftovers

🤖 Generated with Claude Code