Prevent recursive re-entry in native PR review workflows

Native review workflows must prevent self-recursion when repository instructions require the reviewer to invoke the same native review command. This applies when a CLI reviewer loads AGENTS/skill instructions from the target repository; the launcher should set a reviewer-only guard or use a trusted execution context that cannot re-enter the orchestration workflow. The limit is that ordinary direct reviews without repository-level delegation rules are unaffected.

Why it matters: - A parent workflow that delegates to codex review can become codex review → repository review skill → codex review → …. - Increasing timeouts, switching sandbox modes, or improving output redaction does not fix this control-flow loop. - Diagnose it by inspecting sanitized process ancestry or the sanitized native transcript. If a review process launches another review at the same base/head, terminate the descendant chain and treat the verdict as unavailable, never clean. - A durable fix should make the native reviewer ignore orchestration-only instructions or carry an explicit non-reentrant review-depth flag.

Evidence/example (2026-09-09, source: local process ancestry and sanitized Codex review transcript for e3-solutions/theft PR #813): A required no-bwrap native review repeatedly failed to reach a terminal verdict. The sanitized transcript showed the reviewer invoking another codex review, whose descendant repeated the same repository workflow. Multiple sandbox and redaction-wrapper retries changed the surrounding failure symptoms but not the recursive mechanism. No push was performed because a clean verdict could not be established.

Uncertainty: The exact best guard belongs in the shared review launcher/workflow and was not implemented here; the evidence establishes the recursion mechanism, not which host-level mitigation is preferred.