docs: explain opt-in verified Codex clean reviews #30

Source engine PR: RandomDevelopment/ci-fleet#134
Source adopter issue: https://github.com/RandomDevelopment/rd-delivery-config/issues/56
Status: engine PR #134 merged after clean exact-head Codex review and passing hosted validation. Template guidance remains outstanding. Post-merge main CI also passed on the merged engine commit: https://github.com/RandomDevelopment/ci-fleet/actions/runs/38686095709. Host activation remains a separate gate.
Reviewed engine PR head: 4b58ef413c7ea8f7782896f841af23bb1cf757c0. Codex reported no major issues; hosted run https://github.com/RandomDevelopment/ci-fleet/actions/runs/38683846441 passed, including the complete worker-installer suite.
Merged engine commit: f5d3c45dd4eb09ac9cefe16bde7a457673fff678.
Immutable engine contract: https://github.com/RandomDevelopment/ci-fleet/blob/f5d3c45dd4eb09ac9cefe16bde7a457673fff678/docs/CONFIGURATION-APPROVAL.md

Gap: template guidance added by #23 describes formal exact-head approval only. Engine PR #134 adds an explicit host-local codex_reviewer_ids opt-in for verified clean Codex comments. It must not be provisioned against the older formal-only engine.

Affected template files: README.md and docs/UPDATING.md. The engine owns host/config-review-policy.json.example and the verifier; do not invent a fleet.json approval field. No fleet schema, initializer, or validator change is required. The engine adds the configuration_codex_reviews capability for the host-policy syntax.

Acceptance checks:

• Link the immutable merged engine approval contract once available. Explain the pinned independent numeric bot identity, explicit opt-in, unedited recognized clean response, full commit resolution, resolved threads, retarget and newer-review/request rejection, and the separate non-authoritative activity dashboard. Document exact dashboard structure/state fields and the requirement for fresh review after later comment deletion or possible request-erasing edits. GitHub deletion-history evidence must be available and completely paginated.
• Preserve formal approvals by default, exact applied-tree/ancestry checks, successful applied-SHA push workflow/jobs, trusted installed and recovery baselines, API fail-closed behavior, and least-privilege read access.
• Explain that format changes fail closed and that a comment, reaction, successful PR CI, merge, or template release alone does not prove host acceptance.
• Check documentation links, examples, configuration names, and applicable template validation. Preserve historical release records and the hard-disabled deployment boundary.

Capability staging: require configuration_codex_reviews on the selected engine, executing manager, and checkpoint managers before provisioning the optional host-policy field, including an empty list. Active-policy admission and rollback checks reject incompatible targets before mutation or restoration. Install the reviewed supporting engine and compatible executing manager first. When active optional capabilities require evidence, use the existing two integrated staging/promotion commits and immutable engine refs. Keep manager staging distinct from runtime activation.

Migration: no fleet data-schema migration. Omitting the opt-in or using an empty list preserves formal-only behavior. Older engines reject the field, including an empty value; remove it before any separately authorized downgrade. Preserve review-capable recovery state and separately authorized isolation, upgrade, acceptance, and timer-cycle checks.

Documentation impact: operator adoption guidance only. Track implementation here until verified; this issue does not authorize template merge, release, private adopter changes, or live-host activation.