feat(security): implement in-memory fallback for OS keychain (fixes #8)

[Diwakar-odds]

Pull Request

Summary

Implemented OS Keychain fallback mechanism (Fixes #8).

---

Related Issue

Fixes #8

---

Type of Change

• Bug fix
• New feature
• Documentation update
• Performance improvement
• Refactoring
• UI/UX enhancement
• Tests
• Other

---

Changes Made

• Modified src-tauri/src/services/keychain.rs to implement an in-memory OnceLock<RwLock> fallback storage mechanism.
• If the OS keyring crate fails to store, retrieve, or initialize due to platform restrictions, it now gracefully falls back to the in-memory cache, satisfying Phase 5 requirements.

---

Testing

• Tested locally
• Existing tests pass

---

Checklist

• My code follows the project's coding standards.
• I have tested my changes locally.
• I have updated the documentation where necessary.
• My changes do not introduce new warnings or errors.
• I have reviewed my own code.
• This pull request focuses on a single feature or fix.
• I have linked the related issue.

---

Additional Notes

Ensures robust failure handling in headless/unsupported linux environments for CI and container builds.

[Diwakar-odds]

Hi maintainers! Thanks for reviewing this PR.

Technical Analysis

This PR closes the final gap in Issue #8 by implementing the graceful fallback mechanism for the OS keychain. When running in environments where keyring::Entry initialization or password setting fails (e.g., CI environments, misconfigured Linux secret services, or locked keychains), the keychain service now cleanly falls back to an in-memory OnceLock<RwLock<HashMap<String, String>>>. This ensures that API keys (like OpenRouter) can still be set and retrieved temporarily without crashing the application.

ECSoC26 Label Justification

Based on the ECSoC '26 Guidelines, this PR involves:

• Level 3 (Core/Arch/Perf): Implementing graceful failure boundaries and fallback data structures for core security storage is a backend architectural feature. It hardens the security service against native OS integration failures.
• good-backend: This completes the robust state management for sensitive credentials natively in Rust.

Could you please review this PR and consider adding the ECSoC26, ECSoC26-L3, and good-backend labels if you agree with the assessment?

Thanks!

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.