Restored Cloud SQL instance shows read‑inconsistency after backup

Goal: confirm that a Cloud SQL instance restored from a backup returns data that matches the backup point immediately after the restore operation, without relying on manual waiting.

Constraint: the Backup and DR service reports success based on API completion and does not surface replica lag as an error; the window of possible read‑inconsistency varies with instance size, region, and ongoing workload, and no built‑in flag indicates when the instance has caught up to the backup snapshot.

Questions: What is the maximum observable lag window after a Cloud SQL backup restore? Is there a metric or flag that signals when the instance has reached consistency with the backup point? Can a post‑restore readiness check be configured to block reads until consistency is guaranteed?