feat(core): version configuration schema and define 1.0 migrations

[joshrotenberg]

Problem

Profiles are persistent user data, but the TOML configuration currently has no explicit schema version or documented migration policy. A 1.0 support promise needs a safe path for evolving profiles, keyring references, defaults, and authentication metadata without silently breaking existing installations.

Work

• Define and document a configuration schema version.
• Preserve loading of supported legacy 0.x configurations, including Cloud, Enterprise, and direct database profiles.
• Decide whether migrations are transparent, explicit, or both.
• Make rewrites atomic and recoverable; do not lose unknown data or credentials silently.
• Add representative legacy fixtures and round-trip/migration tests.
• Define behavior for configurations produced by a newer redisctl version.
• Document backup, recovery, and environment/keyring precedence.

Acceptance criteria

• 0.11/0.12-era profile fixtures load successfully or produce a precise actionable migration error.
• Any on-disk rewrite is atomic and has a documented recovery path.
• Schema/version compatibility is covered by automated tests.
• Future schema changes have an established migration mechanism and review checklist.

Parent: #1090.

[joshrotenberg]

Initial configuration-safety audit (2026-08-11)

The issue is release-critical, but the current implementation couples several risks that should be addressed in a deliberate order:

• Config::load_from_path expands environment variables across the entire TOML text before parsing. The in-memory model therefore loses the original ${VAR} references, and a later profile mutation/save can serialize resolved secret values back to disk.
• Config::save_to_path writes directly to the destination. An interruption, disk error, or concurrent reader can observe a truncated/partial configuration; there is no backup or recovery marker.
• Serde currently ignores unknown top-level/profile fields, and an existing edge-case test explicitly blesses that behavior. Loading and then saving through an older binary silently drops data introduced by a newer version.
• There is no schema discriminator, so a newer file is indistinguishable from a legacy file and cannot produce a precise compatibility error.
• Config and Profile are publicly constructible structs. Adding private preservation state or new required fields intersects refactor(1.0): reduce and stabilize published Rust API surfaces #1088 and must be coordinated with the pre-1.0 Rust API cleanup.

Proposed implementation order:

1. Introduce an explicit persisted schema version with legacy-version detection, representative 0.11/0.12 fixtures, and a hard actionable error for unsupported newer schemas. Loading must remain non-mutating.
2. Separate persisted source values from resolved runtime credentials so ${VAR} and keyring: references survive edits and saves. Preserve unknown data when rewriting, or refuse to rewrite when lossless preservation cannot be guaranteed.
3. Implement same-directory atomic replacement plus a documented recoverable backup strategy, including failure-path tests.
4. Add explicit migration/repair commands or messaging only after the non-mutating parser and lossless writer are established; document environment, stored value, and keyring precedence.

The first PR should establish the format/version boundary and fixtures without silently rewriting user files. This comment leaves #1084 open.