Replace plaintext token storage with secure credential storage

[hex2dec]

Problem

auth login currently persists access tokens as plaintext in local configuration. This treats secrets like ordinary settings and does not meet modern CLI security expectations.

Root Cause Analysis

The authentication flow uses the same on-disk configuration path for both normal settings and persisted credentials. There is no dedicated credential storage abstraction and no secure OS-backed storage path, so secrets end up in a plaintext config file by design.

Fix Plan

1. Replace plaintext token persistence with a dedicated secure credential storage approach.
2. Keep normal CLI configuration separate from secret storage.
3. Remove the current plaintext credential persistence path instead of maintaining backward compatibility.
4. Preserve stable authenticated command behavior once credentials are stored through the new path.

Acceptance Criteria

• Persisted tokens are no longer stored as plaintext in normal CLI settings by default.
• The CLI uses a dedicated secure credential storage path for saved tokens.
• Existing plaintext token persistence is removed instead of maintained.
• auth status and other authenticated commands continue to work with the new storage flow.
• All new tests pass.
• Existing tests still pass.

[hex2dec]

I took a look at the current auth flow and I think the refactor should be framed around a clear separation of responsibilities:

• CLI configuration should keep non-secret settings only.
• Saved credentials should move to a dedicated secure storage layer backed by the OS credential store.
• Runtime token resolution should remain predictable, with environment variables continuing to override saved credentials for CI and other ephemeral environments.
• Auth commands should keep their external behavior stable even if the persistence backend changes underneath.

At a high level, I would approach this as introducing a credential storage abstraction first, then moving auth login, auth status, and auth logout to depend on that abstraction instead of treating the config file as the source of truth for secrets.

I would also keep this issue scoped to local credential handling only. In other words, the goal here is to stop persisting tokens as plaintext and separate secret storage from normal config. Changes to how tokens are sent to the Gitee API should be treated as a follow-up concern unless we discover that the storage refactor cannot be cleanly isolated.

One implementation detail that seems important to settle early: whether we want to hard-require secure storage and fail when it is unavailable, or support a temporary migration path for existing plaintext tokens while still removing plaintext as a supported steady-state backend. My preference is to treat plaintext config as legacy state to be migrated away from, not as an ongoing storage mode.

[hex2dec]

To help narrow the scope, I think there are three decisions worth making up front:

1. Should secure OS-backed credential storage be the only supported persistence model going forward, or do we want to keep any plaintext fallback behavior?
   My preference is: secure storage should be the only supported steady-state model, while plaintext config is treated only as legacy state that may be read temporarily for migration.

2. Should environment-based authentication continue to take precedence over persisted credentials?
   My preference is yes, since that keeps CI and ephemeral environments predictable and avoids unnecessary local persistence.

3. Should this issue stay strictly scoped to local credential storage, or also include changes to how tokens are sent to the Gitee API?
   My preference is to keep this issue focused on storage only, and treat request-level token transport as a separate follow-up unless the implementation turns out to be tightly coupled.