feat(auth): use OS keyring in bundle distributions

[l2ysho]

Closes #1170.

Problem

The OS-keyring storage from #1148 works for npm install -g apify-cli but not for the bundle distributions (install-cli.sh / install-cli.ps1). Those bundles are built with Bun's --compile. The @napi-rs/keyring wrapper resolves its native .node at runtime via createRequire(__filename)('@napi-rs/keyring-<platform>'), and --compile does not follow that indirection — so no native module was embedded and bundle users silently fell back to plaintext file storage (secretsBackend: "file", token in cleartext) even with a working keyring present.

Approach — embed one platform subpackage per bundle

The key constraint (per Bun's docs: "the .node file must be directly required or it won't bundle correctly") is that the native module must be referenced by a literal specifier that survives to the --compile step. Verified empirically: only a literal dynamic import('@napi-rs/keyring-<platform>') embeds and runs; static named/default imports either fail to bundle or crash with __require is not defined in ESM output, and createRequire isn't bundled at all.

• scripts/build-cli-bundles.ts — a placeholder keyring specifier is kept external in the fat-JS step so the literal import() survives, then rewritten per target to @napi-rs/keyring-<platform> before --compile resolves and embeds that one .node. The rewrite/write runs once per subpackage rather than per target (baseline variants share their sibling's subpackage).
• src/lib/credentials.ts — imports that placeholder in bundle mode (useCLIMetadata().installMethod === 'bundle', the codebase's standard bundle signal) and the @napi-rs/keyring wrapper otherwise. All fallback/migration behavior is unchanged.
• package.json — pnpm.supportedArchitectures so every target's native subpackage is installed at build time. Scope: affects only pnpm install inside this repo (contributors/CI); npm consumers and the shipped bundle are unaffected (npm ignores the pnpm field; bundle users get a single embedded .node).
• src/lib/typings/keyring-native-subpackage.d.ts — ambient declaration so tsc/oxlint accept the placeholder specifier.
• src/commands/auth/login.ts — drops the now-obsolete "install via npm for keyring" hint.

Verification

All four acceptance criteria verified end-to-end by compiling the real credentials.ts into a bun-linux-arm64 bundle and running it against a real D-Bus + gnome-keyring Secret Service:

1. ✅ Legacy plaintext auth.json migrates → secretsBackend: "keyring", token removed, proxy password stripped.
2. ✅ Token + proxy-password discoverable under service com.apify.cli from a separate process (secret-tool search).
3. ✅ With no working keyring: graceful fallback to secretsBackend: "file", no crash.
4. ✅ npm path unchanged — 23/23 credential tests pass.

lint, format, build, tsc all green. test:local: 304 passed; the only 2 failures are pre-existing Python actor-run fixtures (no Python runtime in CI sandbox), unrelated to this change.

Note for reviewers

Criteria 1 & 2 were validated in a hand-rolled keyring environment; a sanity check on a real macOS/Windows/Linux desktop with pnpm run build-bundles is worth doing before release.

🤖 Generated with Claude Code

[l2ysho]

This is the main hack, --compile (bun) skipped napi-rs due to its dynamic require shenanigans -> we provide literal for specific bundle which is shipped as external subpackage (per arch).

https://bun.com/docs/bundler/executables

[l2ysho]

Testing bundles in progress, but feel free to review.

[patrikbraborec]

I did review using Claude Code and Fable 5. Here is the one thing that might be interesting:

In build-cli-bundles.ts, the keyring rewrite was inserted after the Windows ARM64 special case that overrides arch = 'arm64'. CI has a windows-11-arm matrix job, so this path is live. Those bundles are still compiled with target: 'bun-windows-x64' — the output is an x64 PE that runs under x64 emulation on ARM64 Windows. The rewrite, however, computes keyringSubpackage('windows', 'arm64', …) → @napi-rs/keyring-win32-arm64-msvc, a plain ARM64 DLL. An x64 process (even emulated on ARM64 Windows) can only load x64 or ARM64EC DLLs, so LoadLibrary will fail, the dynamic import throws, and the code falls back to file storage — recreating the exact plaintext-fallback bug this PR fixes, for Windows ARM users only. Fix: capture the target's declared arch before the override (or move the rewrite above the override block) so these bundles embed win32-x64-msvc, which loads fine under emulation. It degrades gracefully today, so this isn't a blocker, but it's a two-line fix and otherwise the issue will be invisible until someone debugs it again.

[vladfrangu]

Ocne we merge my PR for unified CLI bundles the arm64 Windows remark won't matter anyways, so lets deal with that first