Authorize tenant-engine lifecycle actions (FLEX-WP-0010)

Extend the tenant-engine write-API policy package with tenant.update,
tenant.retire, and tenant.reactivate, the three actions TEN-WP-0005
introduced. Until now every lifecycle mutation resolved to deny
unknown_action, blocking TEN-WP-0005-T05 production rollout.

- policy_package.md: three actions in valid_actions and frontmatter;
  CARING capabilities extended with EditAny/Archive/Restore
- protected_system_manifest.yaml, subject_manifest.yaml, and the rebuilt
  registry_snapshot.json carry all seven actions
- docs/tenant-engine-action-vocabulary.md documents the HTTP surfaces
- 8 new fixture pairs and 5 new Rego tests, including action-drift
  guards (tenant.retired, tenant_update -> unknown_action)

T02 decision, recorded in policy_package.md: tenant.retire does NOT get
stricter authorization yet. With one service subject and no assurance
claim in the CheckRequest there is nothing stricter to check, and a
condition the sole caller always satisfies would falsely read as
separate control. Retirement is reversible and non-destructive. Revisit
on KEY-WP-0005 assurance claims or a second operator subject.

Verified: 11/11 Rego tests, 16/16 fixtures, go test ./... green, gofmt
and go vet clean. End-to-end against a live serve with a real
tenant-engine through the unmodified FlexAuthWriteAuthorizer: update
6176c39c2f4d7b15, retire 8a801b8ee8455080, reactivate c64cf3713cecd970
all allow; unregistered actor denied unknown_subject
(59d3e99c6416be89, 403 write_denied).

Handoff revision for TEN-WP-0005-T05: package
tenant-engine.write-api.mutate v1 (ready, caring-0.4.0-rc2).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

examples/tenant-engine/policy_package.md

@@ -10,6 +10,9 @@ actions:
   - tenant.role.grant
   - tenant.role.revoke
   - tenant.plan.assign
+  - tenant.update
+  - tenant.retire
+  - tenant.reactivate
 owner: team:platform-security
 fixtures:
   - policy_fixtures.yaml
@@ -33,6 +36,9 @@ caring:
     - Grant
     - Revoke
     - Bind
+    - EditAny
+    - Archive
+    - Restore
     - Audit
   exposure_modes:
     - Metadata
@@ -61,6 +67,53 @@ tenant state a *different* protected system's policy might consult via
 `tenant-engine`'s live-lookup endpoint (`FLEX-WP-0008-T03`); conflating the
 two would authorize the wrong thing.
 
+## Lifecycle actions (FLEX-WP-0010)
+
+`tenant.update`, `tenant.retire`, and `tenant.reactivate` gate
+`tenant-engine`'s lifecycle endpoints (`PATCH /tenants/{id}`,
+`POST /tenants/{id}/retire`, `POST /tenants/{id}/reactivate`). The action
+strings are the exact values `authz.FlexAuthWriteAuthorizer` sends; they are
+coordinated between the two repos, not independently chosen here.
+
+They are three actions rather than one `tenant.write` because tenant-engine
+deliberately separated them so policy *can* one day permit renaming a tenant
+without permitting retiring it. Under the current model that separation is a
+seam, not a difference — see the decision below.
+
+### Decision: `tenant.retire` does not require stricter authorization yet
+
+**Decision (FLEX-WP-0010-T02, 2026-08-10): no.** `tenant.retire` is
+authorized by the same rule as the other six actions.
+
+Reasoning:
+
+1. **There is nothing stricter to check.** The subject set is exactly one
+   service identity (`tenant-engine`), there is no second operator to
+   distinguish from, and requests carry no `assurance` claim — the
+   `CheckRequest` shape from FLEX-WP-0008 has no field that could
+   differentiate retirement from an update. A "stricter" rule today could
+   only be stricter in name.
+2. **A rule that cannot fail is worse than no rule.** Adding a condition
+   that the single known caller always satisfies would read, to a later
+   reviewer, as though retirement were separately controlled when it is
+   not. That is a false assurance in a policy package whose job is to be
+   inspectable.
+3. **The blast radius is recoverable.** Retirement is reversible by design
+   via `tenant.reactivate`, and tenant-engine hard-deletes nothing. A
+   wrongly allowed retirement suspends new grants and plan changes until
+   reactivated; it does not destroy tenant state.
+4. **The seam is already cut.** Because the three actions are distinct
+   strings in `valid_actions`, tightening `tenant.retire` later is an
+   additive change to this package — no consumer change, no request-shape
+   change, no coordination round with tenant-engine.
+
+**Revisit when** `KEY-WP-0005` gives callers an `assurance`-bearing identity,
+**or** when a second operator subject is registered against
+`system: "tenant-engine"` — whichever comes first. At that point the honest
+options are an assurance floor on `tenant.retire` or a distinct
+`group:tenant-engine-lifecycle` membership requirement; both are one rule in
+`allowed` plus a `first_denial` branch.
+
 ## Rules
 
 ```rego
@@ -73,6 +126,9 @@ valid_actions := {
   "tenant.role.grant",
   "tenant.role.revoke",
   "tenant.plan.assign",
+  "tenant.update",
+  "tenant.retire",
+  "tenant.reactivate",
 }
 
 known_operators := {"tenant-engine"}
@@ -131,6 +187,46 @@ test_role_grant_allowed if {
   }
 }
 
+test_tenant_update_allowed if {
+  write_api.decision.effect == "allow" with input as {
+    "subject": {"id": "tenant-engine", "type": "service"},
+    "action": "tenant.update",
+    "resource": {"id": "t-1", "type": "tenant", "system": "tenant-engine"}
+  }
+}
+
+test_tenant_retire_allowed if {
+  write_api.decision.effect == "allow" with input as {
+    "subject": {"id": "tenant-engine", "type": "service"},
+    "action": "tenant.retire",
+    "resource": {"id": "t-1", "type": "tenant", "system": "tenant-engine"}
+  }
+}
+
+test_tenant_reactivate_allowed if {
+  write_api.decision.effect == "allow" with input as {
+    "subject": {"id": "tenant-engine", "type": "service"},
+    "action": "tenant.reactivate",
+    "resource": {"id": "t-1", "type": "tenant", "system": "tenant-engine"}
+  }
+}
+
+test_misspelled_lifecycle_action_denied if {
+  write_api.decision.reason == "unknown_action" with input as {
+    "subject": {"id": "tenant-engine", "type": "service"},
+    "action": "tenant.retired",
+    "resource": {"id": "t-1", "type": "tenant", "system": "tenant-engine"}
+  }
+}
+
+test_unknown_subject_retire_denied if {
+  write_api.decision.reason == "unknown_subject" with input as {
+    "subject": {"id": "some-other-service", "type": "service"},
+    "action": "tenant.retire",
+    "resource": {"id": "t-1", "type": "tenant", "system": "tenant-engine"}
+  }
+}
+
 test_unknown_subject_denied if {
   write_api.decision.reason == "unknown_subject" with input as {
     "subject": {"id": "some-other-service", "type": "service"},