Store credentials in system keychain by default

[michael-webster]

Summary

Stores credentials (CircleCI token, Anthropic API key, GitHub token) in the system keychain by default instead of the plaintext config file.

• `chunk auth set` writes to the system keychain unless `--insecure-storage` is passed
• `--insecure-storage` falls back to the config file (existing behavior), with a warning that the credential is stored on disk
• Keychain failures are now fatal — no silent fallback to plaintext. Users on systems without a working keychain must pass `--insecure-storage` explicitly
• `chunk auth status` warns when any credential is coming from the config file and suggests migrating with `chunk auth set`
• Adds `keyring.MockInit()` so tests that exercise keychain paths use an in-memory backend

Migration

Existing users with credentials in the config file continue to work — credentials are still read from both sources. `chunk auth status` will show a warning and prompt them to re-run `chunk auth set` to move credentials to the keychain.

Test plan

• `chunk auth set circleci` saves token to keychain, not config file
• `chunk auth set circleci --insecure-storage` saves to config file and prints on-disk warning
• `chunk auth status` shows warning for any credential sourced from config file
• On a system without keychain (or with keychain locked), `chunk auth set` without `--insecure-storage` fails with a clear error
• `task test` passes

[michael-webster]

Happy to revert these if people think the fallback resolution tests are of dire importance. But a) we want to ditch config file as even an option and b) the keychain dep is harder to test and the code around it is simple.

[schurchleycci]

Claude:

1. Silent keychain failures (authprompt/authprompt.go:334)

if err := keyring.Set(keyring.CircleCITokenKey(baseURL), token); err == nil {
return true, nil
}
// silently falls through to config file
If keychain storage fails (e.g., locked keychain, Linux with no D-Bus), the error is swallowed and the credential silently ends up in the plaintext config file. The user sees “saved to user config” but doesn’t know why the keychain was skipped. This should at least log a warning like “Keychain unavailable, saving to config file instead.”

2. Potential “already stored” check uses resolved config, not keychain truth

In auth.go:595:

if rc.CircleCIToken != "" && !envSet {
io.Printf("A CircleCI token is already stored.\n")
rc.CircleCIToken could be non-empty because the token came from the keychain or from the config file. That’s fine. But it also means if a user has a token only in the keychain, they’ll get the “already stored” prompt — which is correct behavior. Just worth confirming the wording is intentional (“already stored” instead of the old “already stored in config”).

[michael-webster]

Thanks for the review Scott!

1. Fixed — keychain failures are now fatal rather than silently falling back to the config file. Users on systems without a working keychain need to pass --insecure-storage explicitly. Also added keyring.MockInit() to the keyring package so tests that exercise these paths use an in-memory backend instead of the real system keychain.

2. The wording is intentional — "already stored" is deliberately source-agnostic since the token could be in either the keychain or config file depending on how it was saved.