chore(consul-postgres-ha): pin provider exactly + document disk-loss rejoin

Two small follow-ups after verifying the v0.2.0-beta.3 env-update path
against the live cluster:

1. Provider pin in cluster.tf changed from `>= 0.2.0-beta.3` to
   `0.2.0-beta.3` exactly. Terraform's `>=` operator does NOT include
   later prerelease versions, so `>= 0.2.0-beta.3` only matches stable
   `>= 0.2.0` — `terraform init` failed with "no available releases
   match the given constraints". Pin exactly until we hit a stable.

2. FAILOVER.md gains a disk-loss rejoin section: stop patroni, wipe
   the patroni-pgdata volume, restart, watch Patroni's bootstrap path
   pull a full pg_basebackup from the leader over mesh-conn's QUIC
   tunnel. Measured 5.2 MB / 7s end-to-end on the live cluster
   (handshake-dominated for a small dataset; the real throughput
   number remains the ~25 MB/s pg_basebackup observed during the soft
   -kill section). Closes the last "What this demo does NOT cover"
   item.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: h4x3rotab

consul-postgres-ha/stage4/FAILOVER.md

@@ -172,6 +172,38 @@ signals.
   new timeline. No pg_basebackup, no multi-MB re-copy through
   mesh-conn.
 
+## Disk-loss rejoin (full pg_basebackup variant)
+
+A replica whose pgdata is wiped goes through Patroni's bootstrap path
+and pulls a full pg_basebackup from the leader, all over mesh-conn's
+QUIC tunnel. Recipe (run on a non-leader CVM):
+
+```bash
+docker stop -t 5 dstack-patroni-1
+rm -rf /var/lib/docker/volumes/dstack_patroni-pgdata/_data/*
+docker start dstack-patroni-1
+```
+
+### Measured timeline (run from 2026-05-03)
+
+```
+T_wipe         21:13:41   docker stop + rm -rf pgdata on worker-5
+T_restart      21:13:42   docker start
+T_basebackup   21:13:47   "trying to bootstrap from leader 'worker-4'"
+T_complete     21:13:54   "replica has been created using basebackup"  +7s
+T_streaming    21:13:58   service registered, streaming WAL              +16s total
+```
+
+5.2 MB pgdata transferred in ~7 seconds end-to-end. Note the dataset
+is small enough that handshake/startup overhead dominates — for a
+realistic throughput number, see the soft-kill section's pg_basebackup
+trace at ~25 MB/s sustained on the QUIC path.
+
+The path itself is the proof point: Patroni correctly detects empty
+pgdata, picks `bootstrap from leader` (not WAL replay), pulls the full
+backup over mesh-conn, transitions to streaming on the current
+timeline. No operator intervention.
+
 ## What this demo does NOT cover
 
 * **CVM reboot or kernel panic** — `reboot`/`poweroff` from inside
@@ -182,8 +214,3 @@ signals.
 * **Network partition**: split-brain isolation between coordinators
   vs workers. Patroni + Consul should handle it, but worth a separate
   test before claiming partition-tolerance.
-* **Disk loss on rejoin**: if the ex-leader's pgdata is wiped, rejoin
-  WILL trigger a full pg_basebackup through mesh-conn. The
-  ~25 MB/s throughput and the QUIC transport mean even a 10 GB
-  rebuild takes ~7 minutes (acceptable), but it's a different code
-  path than the cheap rejoin shown above.

consul-postgres-ha/stage4/cluster-example/cluster.tf

@@ -15,11 +15,13 @@ terraform {
   required_providers {
     phala = {
       source = "phala-network/phala"
-      # >= 0.2.0-beta.3 is required for in-place env-block updates to
-      # actually take effect — earlier versions silently no-op'd them
-      # (Phala-Network/phala-cloud#246, fixed in
-      # Phala-Network/terraform-provider-phala#8).
-      version = ">= 0.2.0-beta.3"
+      # 0.2.0-beta.3 is the first version where in-place env-block
+      # updates actually take effect — earlier betas silently no-op'd
+      # them (Phala-Network/phala-cloud#246, fixed in
+      # Phala-Network/terraform-provider-phala#8). Pin exactly because
+      # Terraform's `>=` operator doesn't include later prerelease
+      # versions; bump this line by hand when a newer beta ships.
+      version = "0.2.0-beta.3"
     }
   }
 }