feat(flr): windows paths, recovery-site gate, stable partition reads (#4)

docs/recover-ladder.md

@@ -11,7 +11,29 @@ known path (config, dropped file, one directory).
 
 FLR mounts a checkpoint and copies files out. The protected VM stays up.
 Official API: `POST /v1/flrs` then browse/download. This MCP writes the file
-to `recovery_dir` on the MCP host. Putting it back on the guest is a second
+to `recovery_dir` on the MCP host.
+
+**FLR runs at the VPG's recovery site**, because that is where the mount is
+created. A VPG replicating to a cloud ZCA must be recovered through that ZCA's
+API, not the protected ZVM's. A production server would hold credentials for
+every ZVM/ZCA in the estate and route the call; this one does not, so
+`zerto_recover_file` is gated to **locally replicated VPGs** (protected site ==
+recovery site) and refuses anything else while naming the site that owns the
+operation.
+
+Paths are rooted at partitions, and Linux and Windows are not symmetrical:
+
+| | guest path | FLR path |
+|---|---|---|
+| Linux | `/home/j/app.yaml` | `Volume2-Ext4%2fhome%2fj%2fapp.yaml` |
+| Windows | `C:\Users\j\app.conf` | `C%3a%2fUsers%2fj%2fapp.conf` |
+
+On Windows the drive letter **is** the partition name, so nothing is
+prepended. Browse form-encodes: `%2f` separator, `%3a` drive colon, and a
+space as `+` (`Program+Files`). A session reports mounted before volume
+enumeration settles, so the partition list must be polled until it stops
+changing -- an early read can show a restorable NTFS disk as
+`Volume4-Unknown`. Putting it back on the guest is a second
 step (scp/ssh). That copy-back is not Zerto; it is ordinary file transfer.
 
 Do not use FLR when: