[Feature] Implement Encrypted File Fallback for Keychain Storage

[sunxiaoguang]

Problem Statement

Currently, lark-cli relies on the system keychain on macOS to store sensitive information like App Secrets and User Access Tokens. However, in certain environments—such as restricted sandboxes, headless CI/CD servers, or remote SSH sessions —the system keychain may be unavailable.

When this happens, the CLI currently fails to save configurations, preventing users from completing lark-cli config init or logging in.

Proposed Solution

Introduce a secondary, locally-managed encrypted storage layer. If the primary system keychain is unreachable or returns an "unavailable" error, the CLI should gracefully degrade to storing credentials in an AES-GCM encrypted file within the user’s config directory.

Requirements

• Encryption: Use AES-GCM with a locally generated master.key (permission 0600) to ensure data at rest is not plain text.
• Transparency: Warn the user when a fallback is being used so they are aware of the storage change.
• Safety: Ensure that changing an App ID doesn't lead to the accidental reuse of a secret reference from a previous configuration.
• Refactoring: Centralize config directory resolution and encryption logic to avoid duplication across platform-specific files.