Record tenant-engine guardrail pin and handoff caveats

Operator applied their committed TEN-WP-0007 digest. Notes they asked
us to keep: commit≠image, no plan-layer feed, one-way rollback for
overrides.

examples/tenant-engine/README.md

@@ -128,6 +128,29 @@ after pin:
 Rollback target is `sha256:9320df39` (seven-action). `flex-auth-user-engine`
 was not moved.
 
+Consumer pin (operator apply 2026-08-16, TEN-WP-0007 step 2): live
+`tenant-engine` is
+`sha256:44ca65f3cdd5967b0124e16b6aba10bf1ac2747e1dde96cbef3dd11ae7cc9574`
+(`main-955fe33`). Previous live digest was
+`sha256:2249e8c6ee44ae36081cddc52daf9c3f63acd18a95a5d620ab4fa7ac85149207`.
+Their documented rollback image is
+`sha256:08be0b1dcdc65575592b7be665c28e09a82316ea3d4c9b551ccb753f25360612`
+(TEN-WP-0005 lifecycle). `/health` is `0.1.0`; OpenAPI lists 12 paths
+including `/tenants/{tenant_id}/guardrails`.
+
+Recorded from their handoff, so a later result does not surprise us:
+
+- Newest commit is not always the newest image. After `955fe33` three
+  non-trigger commits landed and no build fired; they pinned the verified
+  digest, not `HEAD`.
+- A guardrail read is sourced from an override or a grouping default.
+  The plan-derived precedence layer has no feed (adaptive-pricing exposes
+  no plan-derived ceilings). A missing plan layer is not a flex-auth
+  policy gap.
+- Rolling their image back is safe one way only: the old image ignores
+  the new tables, but an override written on the new image stops being
+  enforced after rollback. Inert until something consults guardrails.
+
 ## Related
 
 - `docs/tenant-engine-resource-namespace.md`