Flaky postgres integration test: read replica phase races the primary's first backup

[sdairs]

Problem

The Read Replica phase of cloud_postgres_crud_lifecycle creates the replica seconds after the primary reaches running, but replica provisioning gates on the primary having a completed first backup. Two observed failure modes:

• Create rejected: 400 BAD_REQUEST: Parent server is not ready for read replicas. There are no backups, yet. (main scheduled run 2026-06-29, PR Resolve OpenAPI drift: slow query patterns, Postgres metrics, RPE update (#224) #273 run 2026-06-26)
• Create accepted, replica never runs: replica sits non-running past the 1800s steady-state timeout (PR Unblock postgres_instance_config PATCH (#163) #215 run 2026-07-05)

Not AWS capacity — create is accepted/rejected instantly, no capacity errors in logs.

Proposal

The test only needs to prove the API surface works, not that provisioning completes. Drop the wait for postgres read replica running step and keep:

1. Create → assert response shape (isPrimary=false, name, sane state)
2. Replica visible in postgres_service_get_list alongside primary (any state)
3. postgres_service_get on replica returns matching provider/region (any state)
4. Delete replica → confirm gone → delete primary

Deleting a still-provisioning replica is proven safe: the failed PR #215 run's cleanup deleted the stuck replica in ~11s and the primary deleted cleanly after.

Callouts

1. The non-empty hostname/connection_string assertions currently ride on the running-state poll result. They test the provisioned instance, not the API — drop them, or keep as tolerant checks on the create/get response if populated early.
2. Dropping the wait doesn't fix the first failure mode: create itself can still be rejected with the "no backups yet" 400. Wrap create in a retry that treats that specific 400 as retryable, otherwise the flake just moves to the create step.

Worth separately flagging to the cloud team that the API inconsistently accepts a replica create against a backup-less primary and leaves it non-running for 30+ min — the 400 rejection seems like the more correct behaviour.