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>

docs/tenant-engine-action-vocabulary.md

@@ -12,8 +12,19 @@ repos, not independently invented.
 | `tenant.role.grant` | `POST /tenants/{id}/roles/grant` | `role-grant` | `allow`, `deny` |
 | `tenant.role.revoke` | `POST /tenants/{id}/roles/revoke` | `role-grant` | `allow`, `deny` |
 | `tenant.plan.assign` | `POST /tenants/{id}/plan` | `plan-assignment` | `allow`, `deny` |
+| `tenant.update` | `PATCH /tenants/{id}` | `tenant` | `allow`, `deny` |
+| `tenant.retire` | `POST /tenants/{id}/retire` | `tenant` | `allow`, `deny` |
+| `tenant.reactivate` | `POST /tenants/{id}/reactivate` | `tenant` | `allow`, `deny` |
 
-These are the only four actions `tenant-engine` sends to `POST /v1/check` —
+The last three are the tenant lifecycle actions added by `FLEX-WP-0010` for
+`TEN-WP-0005`. They are three actions rather than one `tenant.write` because
+tenant-engine separated them so policy *can* permit renaming a tenant without
+thereby permitting retiring it. Under the current single-operator model all
+three resolve identically — the separation is a seam for later, and the
+reasoning for not yet treating `tenant.retire` more strictly is recorded in
+`examples/tenant-engine/policy_package.md`.
+
+These are the only seven actions `tenant-engine` sends to `POST /v1/check` —
 its `FlexAuthCheckClient` (`TEN-WP-0003`) never sends anything else, and
 `tenant-engine`'s reads (`/roles`, `/roles/live`) are never gated through
 flex-auth at all; they're `tenant-engine`'s own cache-read and live-lookup
@@ -24,7 +35,10 @@ endpoints, consumed *by* `key-cape` and `flex-auth` respectively.
 `tenant-engine`'s capability roles (`PLTF`/`IAM`/`VEN`/`CUS`, ADR-0014) are
 **tenant** state — what a tenant is allowed to do on the platform. This
 vocabulary governs a different question: which **operator/service
-subjects** are allowed to call `tenant-engine`'s admin API at all. The two
+subjects** are allowed to call `tenant-engine`'s admin API at all. The
+lifecycle actions do not change that boundary: `tenant.retire` asks whether
+*this caller* may retire a tenant, not what a *retired tenant* may still do —
+the latter is tenant state that tenant-engine enforces itself. The two
 must not be conflated — a policy package that checked a *caller's* action
 against a *tenant's* capability roles would be checking the wrong thing.
 See `examples/tenant-engine/policy_package.md`'s Rules section for how the