code-review skill: nested-fork not supported at high+ effort causes runaway sub-agent duplication

### Environment
- Claude Code CLI version: 2.1.267
- Platform: macOS (Darwin)
- Trigger: the built-in `/code-review` skill, invoked with `--comment` against a private, company-controlled GitHub repository (details redacted below since the repo is private)

### Summary
At `high`/`xhigh`/`max` effort, the built-in `/code-review` skill's internal fan-out step relies on a second level of agent forking that the platform does not support. The failure mode is inconsistent: some invocations silently fall back to a safe sequential path, but others get confused about their own role/identity and recursively re-spawn the full fan-out, producing runaway background agents and duplicate/garbled output. This happened consistently once I ran the skill at high effort, and got much more visible when I ran several invocations of it concurrently (once per pull request, ~7 in parallel) in the same session.

### Steps to reproduce
1. In a repo with several open pull requests, invoke the `/code-review` skill (either via the slash command or via the `Skill` tool) with `--comment` and no explicit effort level, or with `high`/`xhigh`/`max` effort, against one or more PRs.
2. Optionally, invoke it for several different PRs in the same turn/session (I did 7 in parallel via the `Skill` tool).
3. Observe the background task notifications as each invocation's coordinator agent tries to fan out into its ~8 "finder angle" sub-agents.

### Expected behavior
Either:
- Nested/second-level forking should be supported when the skill's coordinator itself is already running as a forked execution of the caller, **or**
- The skill should reliably detect that a second-level fork is unavailable and deterministically fall back to running all finder angles sequentially in the current context — the same safe path already used by `medium`/`low` effort levels.
- Additionally, if a `--comment` invocation is unable to actually post PR comments (e.g. because no GitHub comment tool is available in that particular sub-agent's context), it should say so plainly rather than reporting success/asking whether to post, since the top-level caller may not always verify against the live PR.

### Actual behavior
- Several forked coordinator sub-agents, upon attempting the second-level fork for their 8 finder angles, produced a self-reported error along the lines of "forking isn't available from inside an already-forked session."
- Some of those sub-agents fell back gracefully to running all 8 angles themselves, sequentially, in the same context (no bug).
- Others did not: they appear to have inherited the full coordinator instructions (including the fan-out instruction itself) and mistakenly concluded that *they* were the top-level coordinator, recursively re-spawning their own set of finder-angle sub-agents. This produced extra, uncontrolled background agents.
- One resulting sub-agent also reported receiving messages from a sibling agent that attempted to reassign its identity/role and extract its results as if it were a different worker; it correctly declined and verified the real agent hierarchy via `ListAgents` rather than trusting the claim, but the fact that this kind of cross-agent confusion is even a possible outcome for a plain PR-review command is concerning.
- Net effect across a session where this was invoked for several pull requests: a significant number of duplicate/garbled inline PR review comments were posted (from multiple sub-agents redundantly re-running the same finder angle), and on two of the pull requests, findings were **not actually posted** despite the sub-agent's summary implying the `--comment` step had completed — this was only caught because the caller independently verified against the live PR state afterward. Cleaning up the duplicate comments required manually diffing comment bodies and deleting the redundant ones via the GitHub API.

### Suggested fix
1. Detect fork depth (or catch the "forking isn't available from inside an already-forked session" condition) deterministically in the skill's own coordinator logic, and always fall back to the safe sequential path used by `medium`/`low` effort — never leave it to the LLM to infer this from ambiguous inherited context.
2. When spawning per-angle workers (whether as forks or fresh agents), explicitly pin each worker's role in its prompt (e.g. "you are a leaf worker for angle X only; do not spawn further agents") so that even with full inherited context, there's no ambiguity about whether the worker is itself a coordinator.
3. Have `--comment` posting steps verify and honestly report whether they actually succeeded (e.g. by checking the tool/API was actually available and calls actually returned success) rather than describing intended behavior as if it happened.

Happy to provide more detail, though I've deliberately omitted the repository name, PR contents, and any code snippets here since this occurred against a private, company-controlled repository.

Start by reproducing `/code-review` through the `Skill` tool at high effort with `--comment`, including concurrent invocations, and trace the coordinator's second-level fork and finder-angle worker paths. Done means nested forking falls back deterministically to sequential execution, workers remain leaf workers, and comment posting reports actual success or failure.

Written by the indexing model from the issue text.