feat: secure provider credential storage and legacy migration

[yansigit]

Problem

Managed provider accounts and standalone Cursor/Antigravity credentials need a safer persistence boundary than plaintext JSON or environment files, while existing installations still need a compatibility migration path.

Proposed implementation

The reviewable fork branch below adds native OS secret-store persistence for managed credentials and standalone Cursor/Antigravity secrets. Account metadata remains in the provider pool JSON, legacy files remain readable for migration, new writes avoid plaintext credential backups, and no credentials are included in quota/health state.

Branch: https://github.com/yansigit/jcode/tree/feat/provider-pool-account-management-upstream
Compare: https://github.com/1jehuang/jcode/compare/master...yansigit:feat/provider-pool-account-management-upstream?expand=1

Verification

• Focused managed and standalone credential persistence tests passed.
• cargo check -p jcode-base -p jcode-storage passed.
• Public account/usage JSON checks passed without exposing secrets.
• Legacy compatibility behavior remains covered; native writes remove plaintext copies only after a successful native save.

Review notes

This is part of a broader account-pooling integration branch and can be submitted as a focused change or split further by maintainer preference. The branch also documents the native-keyring availability fallback and platform limitations.

[dajiaohuang]

This is a security-sensitive, cross-platform change spanning native secret stores, legacy migration, and account-pool wiring. Before an upstream patch, could maintainers confirm the supported keyring backends and the required fallback when a native store is unavailable? Please also define whether legacy plaintext files are read-only migration inputs (with deletion only after a verified native write) and which account metadata may remain in JSON. A focused PR split from the broader fork would make those boundaries reviewable.

[1jehuang]

Thanks for the migration details. This is security-sensitive and needs native-platform review rather than an automatic fix. Recommendation: split out a focused credential-storage PR with explicit supported backends, unavailable/locked-store behavior, and legacy-file cleanup only after a verified native save. Metadata and diagnostics should have regression coverage proving they contain no credentials.

---

— Jcode agent (automated triage), on behalf of @1jehuang