epic: redisctl 1.0 Redis Cloud client readiness audit

Goal

Establish enough evidence and API stability in redis-cloud-rs for redisctl 1.0 to depend on it as the supported Redis Cloud client.

This is not a requirement to implement every API operation. It is a requirement to make the supported surface explicit, current against the published specification, and validated against a dedicated non-production Redis Cloud account.

Existing audit backlog

• #144 — correct the published-version documentation and prevent recurrence
• #145 — test the public error contract
• #146 — close PSC and Transit Gateway request/response test gaps
• #147 — add guarded destructive/mutating lifecycle validation
• #148 — normalize /v1, refresh the bundled OpenAPI document, and reconcile coverage
• #149 — schedule specification-drift detection
• #150 — establish a ratcheting coverage floor
• #151 — schedule safe live contract/compliance validation

Readiness review

• Compare the complete typed route inventory with the current published Redis Cloud OpenAPI document.
• Classify every published operation as supported, deliberately unsupported, or raw-only, with rationale.
• Run the safe compliance matrix against a dedicated test account and review every known difference and skipped category.
• Exercise representative reversible and destructive lifecycles with explicit cost, cleanup, and safety controls.
• Review public model behavior for unknown fields, optionality, numeric/string drift, pagination, async tasks, and error classification.
• Review the consumer-facing API for changes that should happen before the next stable client release.
• Publish an audited crate release with migration notes suitable for redisctl consumption.

Exit criteria

• The bundled specification and route inventory match the current upstream source of truth.
• Live validation covers the critical read and lifecycle journeys used by redisctl.
• Unsupported or unverified areas are explicit and are not described as full coverage.
• CI detects future specification drift and material coverage regression.
• A released crate version is available for redisctl integration; redisctl does not consume an unreleased branch for 1.0.

Downstream

redis/redisctl#1090 will remain blocked until this audit is complete. Downstream integration is tracked by redis/redisctl#1086 and requires the audited crate release plus passing Cloud CLI/MCP contract tests.

Start with the unchecked items in the existing audit backlog and the readiness review, then inspect the evidence from the completed linked issues and the published Redis Cloud specification. Validate the remaining lifecycle, model, and consumer-facing API concerns against the stated exit criteria, including safe live-account controls. Done means the audit is complete, unsupported areas are explicit, CI checks remain in place, and an audited crate release unblocks redisctl.