docs: hub v0.61.0 Customer RESET — REPORT/CONTEXT + ep0 runbook §10 (tenantsync v1.1.0 deprovision, live-drilled)

documentation/runbooks/offsite-endpoint.md

@@ -353,8 +353,16 @@ The hub's SECOND forced-command surface on the endpoint: per-customer PBS tenanc
 privilege-separated token + dual-grant, the §4a dance automated). Same low-priv user as peersync, its
 OWN keypair + script + sudoers drop-in — **the peersync files are untouched** (one script, one job;
 peersync script + sudoers sha256 asserted identical before/after at install). Script source of truth:
-`scripts/felhom-tenantsync.sh` (v1.0.0; JSON stdin/stdout, ops `provision`/`reissue`/`fingerprint`,
-NO deprovision — data deletion stays a deliberate decision). Hub client: `hub/internal/tenantsync`.
+`scripts/felhom-tenantsync.sh` (**v1.1.0**; JSON stdin/stdout, ops
+`provision`/`reissue`/`deprovision`/`fingerprint`). Hub client: `hub/internal/tenantsync`.
+
+> **v1.1.0 (2026-07-17, deployed to ep0):** adds the `deprovision` op — the deliberate data-deletion
+> the slice-1 header reserved, now driven by the hub-side **customer RESET** (hub v0.61.0, operator
+> ack-gated). It destroys the customer's namespace + all backup groups + token
+> (`namespace delete --delete-groups true`); the shared `felhom@pbs` user is never touched; idempotent
+> (`deleted:false` when nothing was there). To update the on-box script, re-run the install block below
+> with the new source (a `.bak-<ver>` is kept). Live-drilled 2026-07-17: provision → real backup →
+> deprovision (`deleted:true`, group destroyed) → idempotent re-run → all real tenants survived.
 
 On the build server (the hub's credential; mirror of step 6):
 ```sh