test(compliance): implement the deferred T4 destructive/mutating write pass

Background

The API compliance harness (tests/compliance.rs) landed in phases 1-3 (#139/#141/#142) and now classifies 100% of the 155-operation surface. Its own header documents that one tier is deliberately deferred:

T4 destructive / mutating writes (create/delete of subscriptions, databases, cloud accounts; flush; import; upgrade; …) and connectivity/Active-Active writes are Skipped pending the deliberate, guarded destructive pass.

So the create/delete/flush/import/upgrade paths and connectivity/Active-Active writes are currently validated only for request serialization (via the mock unit tests), never round-tripped against the live API the way reads and non-destructive writes now are.

Suggested work

Design and implement the T4 pass as a guarded, opt-in lifecycle:

• Full create -> verify -> delete lifecycles for subscriptions, databases, and cloud accounts, each self-cleaning even on failure (drop-guard / teardown).
• Gate behind an explicit env flag (e.g. REDIS_CLOUD_ALLOW_DESTRUCTIVE=1) on top of the existing --ignored + credentials gating, so it can never run by accident in CI or a normal cargo test.
• Fold results into the existing baseline/drift gate (compliance_baseline.json) once stable.
• Cover connectivity + Active-Active writes currently marked Skip.

This is the natural next phase of the compliance work and the last remaining tier before the matrix is genuinely end-to-end verified.

Found by

Daily automated project review (2026-07-10), from the deferred-work note in tests/compliance.rs.

Start by reading tests/compliance.rs, especially the deferred T4 notes and existing --ignored and credential gating. Trace the skipped destructive, connectivity, and Active-Active cases, then review compliance_baseline.json. Done means an explicit REDIS_CLOUD_ALLOW_DESTRUCTIVE=1 opt-in, guarded create-verify-delete lifecycles with failure cleanup, coverage for the remaining writes, and stable baseline integration.