feat(auth): add credential storage policies

[gnapse]

Summary

• Add CredentialStore policies to createKeyringTokenStore: system, plaintext, and backward-compatible fallback.
• Make strict system writes fail without persisting a plaintext credential; explicit plaintext writes bypass the keyring and always return a warning.
• Allow a policy resolver for CLI options parsed after store construction, and document the API.

Example

let credentialStore: CredentialStore = 'system'

const store = createKeyringTokenStore({
    serviceName: 'example-cli',
    userRecords,
    recordsLocation: configPath,
    credentialStore: () => credentialStore,
})

fallback remains the default to preserve existing consumers. A CLI can expose only system and plaintext, with system as its own default.

Motivated by Doist/todoist-cli#424.

Verification

• npm run build
• npm run type-check
• npm test (35 files, 534 tests)
• npm run check

[doistbot]

This PR adds system, plaintext, and fallback credential storage policies to createKeyringTokenStore, with a resolver pattern for lazy policy selection, full backward compatibility via the fallback default, and appropriate test/README coverage. No inline issues were flagged.

I also included a few optional follow-up notes in the details below.

Optional follow-up notes (3)

• src/auth/keyring/record-write.ts:200: credentialStoreUnavailableError hardcodes 'The system credential manager could not store the credential.', but the existing SECURE_STORE_DESCRIPTION constant (exported from ./secure-store.js) already encapsulates that label and is used for the same purpose in token-store.ts (e.g. accessReadError, fallbackResult). Import and reuse it for consistency: ts import { type SecureStore, SECURE_STORE_DESCRIPTION, SecureStoreUnavailableError } from './secure-store.js' // ... `${SECURE_STORE_DESCRIPTION} could not store the credential.`
• src/auth/keyring/record-write.ts:197: credentialStoreUnavailableError() drops the original SecureStoreUnavailableError's message and cause entirely. SecureStoreUnavailableError is specifically designed to preserve platform diagnostics on cause (per its doc comment in secure-store.ts), and the read path surfaces the underlying reason via accessReadError's (${outcome.detail}). In strict system mode — where knowing why the keyring was unavailable matters most — the user only sees a generic message. Consider threading the original error's message into the CliError (e.g. via getErrorMessage(error)) so system-mode write failures are diagnosable.
• src/auth/keyring/token-store.test.ts:155: This is the only rejection test in the file that pins the exact message string; every other rejects.toMatchObject asserts only the stable code. The wording is an implementation detail, so rewording the user-facing message would break this test without a behavioral regression. Consider dropping the message field to match the rest of the suite (the unit-level test in record-write.test.ts already checks only code).

_{Share Feedback • Review Logs}

[doist-release-bot]

🎉 This PR is included in version 1.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀