/code-review in the desktop app runs inline in the authoring session (no context isolation), and the docs don't say so

## Summary

In the Claude desktop app, `/code-review` runs **inside the current conversation** instead of as a background forked subagent. The agent that reviews the PR is the same agent that wrote it, with the full authoring context. As far as I can tell this is intentional, not a bug, but the docs don't mention it. Anyone relying on `/code-review` for an independent review in the desktop app gets a self-review without knowing it.

## What the docs say

From https://code.claude.com/docs/en/code-review:

> The review runs as a background subagent with its own context window, so it doesn't fill your conversation.

> The review runs in the background by default; before v2.1.218, it ran inside your conversation. It runs in the foreground instead in cases like these: [re-run while a review is in progress / `-p` or Agent SDK / `CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1`]

> In a host application that requests the findings list, such as the desktop app, Claude reports the review's findings through the `ReportFindings` tool instead.

Nothing on that page says the desktop app skips the background subagent, or that the review there loses context isolation.

## What I observed

- Environment: Claude desktop app 2.110.1, bundled Claude Code 2.1.260 to 2.1.271, macOS 27.0.
- 8 of 8 `/code-review` runs started from the desktop app (session entrypoint `claude-desktop`) ran inline:
- The skill prompt was injected as a meta user message into the **main** transcript (`isSidechain: false`).
- The same agent then ran `git diff` and called `ReportFindings`.
- No subagent transcript was created for the review.
- Every run's banner read `minimal prompt → single careful diff pass → ≤15 findings`, and no finder/verifier agents were dispatched. By contrast, a terminal CLI report (#86724) describes `/code-review` forking and fanning out 8 finder agents.
- In one run, the review's first line was literally "Reviewing my own PR — …". The reviewer knew it was the author.
- None of the documented foreground triggers applied: `CLAUDE_CODE_DISABLE_BACKGROUND_TASKS` not set, not `-p`, no other review in progress.
- The desktop app sets `CLAUDE_CODE_REPORT_FINDINGS=1` for the CLI it spawns. The variable shows up in the spawned process environment, and `CLAUDE_CODE_REPORT_FINDINGS="1"` appears in `app.asar`.

## Likely reason (my reading, not confirmed)

In ReportFindings mode, the prompt asks the agent to call `ReportFindings` again later in the same session, marking each finding `fixed` / `skipped` / `no_change_needed`, so the findings card stays up to date. A forked subagent is gone by then, so the review has to run in the long-lived session. That is a reasonable tradeoff (interactive findings card vs. reviewer independence), but it is invisible to users.

## Requests

1. **Docs:** state that in the desktop app (or whenever `ReportFindings` mode is active), `/code-review` runs in the current conversation and does not isolate context.
2. **Option:** let desktop users choose an isolated review. For example, run the review in a forked subagent and have the main session only relay and update the `ReportFindings` card, or add a setting/flag that trades the live card for isolation.

## Related

- #95136: background `/code-review` subagent (CLI, 2.1.274)
- #86724: terminal `/code-review` orchestrator fanning out finder agents
- #60720, #49559, #17283: `context: fork` skills running inline or behaving differently in desktop

Start with the code-review documentation page at https://code.claude.com/docs/en/code-review and review its statements about background subagents, foreground triggers, and ReportFindings mode. Update the documentation to explain that desktop-app reviews run inline in the current conversation without context isolation, and make the behavior and its implications clear to users.

Written by the indexing model from the issue text.