fix: prevent macOS keychain writes from exposing API keys in process list

[bukinoshita]

Summary

Resolves BU-628: macOS keychain writes expose API keys in process list.

The MacOSBackend.set() method was passing the API key as a command-line argument to /usr/bin/security add-generic-password -w <secret>, making it visible to any process listing tool (ps, endpoint monitoring, etc.) during the write.

Summary by cubic

Secure macOS Keychain writes so API keys never appear in process args, and stop auto-migrating credentials during reads. Fixes BU-628.

• Bug Fixes

  • macOS backend now writes via a JXA script piped to /usr/bin/osascript, calling SecItemAdd/SecItemUpdate with secrets sent over stdin.
  • Removed auto-migration from resolveApiKeyAsync; reads never write credentials. Added tests for stdin-only handling and no auto-migration.

• Refactors

  • Reverted arrow functions to function declarations in the macOS backend for consistency.

^{Written for commit 5241187. Summary will update on new commits.}

[bukinoshita]

@cubic-dev-ai review this PR?

[cubic-dev-ai]

@cubic-dev-ai review this PR?

@bukinoshita I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 4 files

[cubic-dev-ai]

No issues found across 4 files

[felipefreitag]

This isn't working for me:

◇  Enter your Resend API key:
│  ▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪
  ✔ API key is valid (full access)
│
◇  Save API key to which profile?
│  qa-test-pr245 (overwrite)
Error: Failed to store credential in macOS Keychain: execution error: Error: Error: Keychain error: -50 (-2700)
 ELIFECYCLE  Command failed with exit code 1.

Likely problem:

1. $.kSec* constants don't work as NSDictionary keys in JXA. They're opaque Ref objects that all hash to the same key, so the dictionary ends up with 1 entry instead of 4. SecItemAdd returns -50 (errSecParam). Fix: use the raw string values ($("class"), $("genp"), $("svce"), $("acct"), $("v_Data")) instead of $.kSecClass, $.kSecClassGenericPassword, etc.

I investigated a bit and got past that error, but then any attempt to read the key keps prompting for keychain access and failing.

2. ACL mismatch between set() and get(). Items written by osascript via SecItemAdd get an ACL that only trusts /usr/bin/osascript. But get() still uses /usr/bin/security find-generic-password -w, which is a different binary — so macOS shows a keychain authorization prompt, the 5s timeout fires, and get() fails with exit code null. Either get() needs to also use JXA/SecItemCopyMatching, or the set() script needs to add /usr/bin/security as a trusted application in the ACL.