Resolve API keys from macOS Keychain

[glenjbarber]

Fixes #67.

What

Adds internal/keychain, a small wrapper around the security CLI for looking up, setting and deleting generic-password items by account/service — the macOS Keychain mechanism issue #67 asks for, so orcli.json can name a credential instead of containing it.

Design decisions the issue left open

• Source: the security CLI (find-generic-password/add-generic-password/delete-generic-password), not the Security framework's native API — the native API has no stable cgo-free binding, and adding cgo to a client that otherwise has none is a bigger cost than the one exposure the CLI carries (see below). The issue's own acceptance criteria already describe -a/-s matching, which is this CLI's own flags.
• Precedence when both an inline api_key and api_key_keychain are configured: the inline key always wins. Migrating means removing api_key from the file, not just adding api_key_keychain beside it — a stale api_key silently continuing to be used with no error is exactly the failure mode this feature exists to avoid elsewhere.
• Listing never touches the Keychain at all — it reads the account/service references already sitting in the config file (never a secret), so "list names/provider association without displaying secret values" has nothing to redact in the first place.

Security properties (the issue's own acceptance criteria)

• Every call goes through exec.CommandContext with an argument array, never a shell — a configured account/service name reaches argv as a single element, never interpolated into a command line.
• A secret value can never reach a returned error, by construction: Lookup separates stdout (the secret) from stderr (the diagnostic) at the type level — the internal commandErr helper's signature only accepts stderr, so stdout isn't available to pass in by mistake. Tested explicitly (TestLookup_FailureNeverLeaksStdout, TestSet_FailureNeverLeaksTheSecret).
• orcli keychain set reads the secret with echo suppressed (golang.org/x/term.ReadPassword) when stdin is a real terminal; the interactive chat session is deliberately not used for this, since it renders input into the transcript.
• The secret reaches security add-generic-password as one argv element — the one exposure this approach cannot avoid while driving this CLI rather than the Security framework's own API, visible only to another local process inspecting the process list at that moment, and documented as such in the README.
• orcli keychain delete NAME removes only the named item, from both the config file and the Keychain.

Testing

Fully testable on Linux CI (which has no security binary and will never run macOS) via an injectable subprocess seam (run in internal/keychain) and a goos variable standing in for runtime.GOOS. New tests across internal/keychain, internal/config, and cmd/orcli cover: lookup success/not-found/failure, the stdout/secret-leak guard, Set/Delete argument shape, config precedence (inline vs. keychain, missing item, no keychain block, lookup-failure propagation), the writer (WriteKeychainItem/DeleteKeychainItem, including that a refused write leaves existing items untouched), the orcli keychain set/list/delete commands end to end, and the startup path (run's own ErrNoAPIKey case resolving via api_key_keychain, and reporting — not silently swallowing — a configured-but-failing reference).

make test passes clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Nxr4mW9rMNzn9kThjdJpZt

---

Generated by Claude Code