feat(keychain): storage for openrouter api key

[bharatsachya]

What changed

• Added @napi-rs/keyring dependency to the @bb/config package to support synchronous access to the OS credential store (macOS Keychain, Linux Secret Service, Windows Credential Manager).
• Created a new keychain utility (packages/config/src/keychain.ts) defining SECRET_KEYS (openrouter_api_key, neo4j_password) and exposing helper functions: getSecret, setSecret, deleteSecret, isKeychainAvailable, isSecretKey, and isKeychainAvailable (availability probe).
• Added storeSecret helper (packages/config/src/secrets.ts) that orchestrates storing secrets in the keychain while clearing any plaintext equivalents from config.json.
• Modified the config loader (packages/config/src/loader.ts) to automatically overlay config schema values with values retrieved from the OS keychain if the local plaintext values are empty.
• Updated packages/server/src/index.ts to log a startup warning if any secret key is found stored in plaintext inside config.json.
• Updated the CLI set command (packages/cli/src/SetCommand.ts), the setup form (packages/cli/src/SetupForm.tsx), and the configuration boot default applicator (packages/cli/src/bootConfig.ts) to route secrets through the new keychain-aware setter mapping.
• Documented secret storage architecture, fallback mechanisms, and public API surface in both CLAUDE.md and packages/config/README.md.

Why

Storing API keys and database passwords in plaintext in a configuration file (config.json) represents a significant security risk. Moving these secrets to the OS-provided secure credential store (Keychain on macOS, Secret Service on Linux, and Credential Manager on Windows) ensures they are encrypted at rest.

Using a transparent fallback to plaintext config.json ensures the application continues to run seamlessly on environments or containers where no secure OS keychain backend is available.

How to test

1. Ensure dependencies are up-to-date by running:

   bun install
   bytebell set/setup

[bharatsachya]

Against #100

[Dead-Bytes]

instead of supporting legacy i think a clean migration is more viable option to go for