docs: tagged checkpoints do work on cloud-protected VPGs

The repo said, in four places, that a tagged checkpoint cannot be inserted
when the protected site is Azure or AWS. That came from the 9.0 API
reference. It is wrong on 10.9.10.

Measured against the lab: both an AWS-protected and an Azure-protected VPG
accepted the insert, the Zerto task reached Completed, and the checkpoint
appeared in the journal. This is the second doc claim this repo carried
that live 10.9 contradicts, after the VPG status enum.

What actually differs is latency and granularity, and both are set by the
PROTECTED site, not the recovery site:

  protected at   journal gap   tag visible after
  vSphere        5s            ~4s
  Azure          60s           ~34s
  AWS            630s          ~128s

There is a sharper consequence than slowness. The tagged checkpoint is
stamped about 30s AFTER the insert request, so on a cloud-protected VPG an
agent that mutates promptly puts its change inside the checkpoint that was
supposed to precede it. Recovering from that tag would restore the broken
state. The docs now say to use the newest checkpoint that already existed
when the guard ran.

Two of the four were message text, not prose. wait_for_tag's timeout
message asserted the insert was unsupported when the real cause was its own
45s budget being far too short for a VPG that checkpoints every 630s, so it
told operators the wrong thing at exactly the wrong moment. It now says to
check the Zerto task before concluding the insert failed.

The 45s timeout itself is still wrong for cloud sources and needs to become
cadence-aware. That is a behaviour change, so it is not in this commit.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

skills/zerto-rewind/SKILL.md

@@ -70,7 +70,10 @@ so a stuck session blocks the next recovery. Find it with
 ## Facts that bite
 
 - A tagged checkpoint is crash-consistent, not app-quiesced.
-- Tagged checkpoints are not supported when the **protected** site is Azure or AWS. Talk to the vSphere protected ZVM.
+- Tagged checkpoints work on Azure and AWS protected VPGs, but they appear late:
+  ~34s (Azure) and ~128s (AWS) versus ~4s on vSphere, and the checkpoint is stamped
+  about 30s after you ask for it. On those VPGs the tag can end up *after* your
+  change, so treat the newest checkpoint that already existed as the rewind point.
 - 10.9 FLR Operator RBAC fails; Administrator is the documented workaround.
 - FLR cannot run during clone, test, live failover, or EJC.
 - Linux FLR: files >1.5GB are a bad idea; some characters in names are refused.