Add two-tier `/review` for PR and branch code review

[puri-adityakumar]

Summary

Add /review and fx review for evidence-based code review. Two tiers only — no one-shot quick mode.

• Default: one read-only find → verify pass
• --deep: parallel finder subagents + independent verify per finding

Why

fx can draft PRs (fx pr) and delegate work (subagent), but has no dedicated review flow. Free-form "review this diff" prompts are inconsistent, and a truncated one-shot pass invents issues easily.

Behavior

/review / fx review

pre-flight (host, 0 model tokens)
  resolve target (branch | PR | current vs merge-base)
  verify ref · require non-empty diff
  prepare truncated patch + file list
       │
       ▼
ONE finder agent (tool loop, enforced read-only)
  prepared diff · read_file · grep_files · glob_files
  budget: bounded tool calls
       │
       ▼
self-verify (same agent)
  re-read every cited file:line
  confidence 0-100 · drop < 80
       │
       ▼
report: P0 / P1 / nit · severity · mandatory file:line

/review deep / fx review --deep

same pre-flight + bounded repo context pack
       │
       ├─▶ subagent.run ①  bug hunt
       ├─▶ subagent.run ②  standards (AGENTS.md / repo conventions)
       └─▶ subagent.run ③  intent (PR/issue description when available)
       │        root-spawned in parallel · read-only · citations mandatory
       ▼
VERIFY FAN-OUT (one independent subagent.run per finding)
  0-100 confidence · keep only ≥ 80
       │
       ▼
dedupe + rank → report
optional --json for CI / editor integrations

Constraints

• Slash and CLI share one workflow
• Read-only is enforced, not just prompted
• Diff prep is host-side (like fx pr), not shell allowlist gymnastics
• Separate from permission/safety review
• v1: no GitHub review comments, no branch mutation, deep stays opt-in

[puri-adityakumar]

One implementation question from checking fx’s current boundaries: the built-in read-only tools are file read/search tools, not shell/git, and subagents do not currently accept a per-child read-only tool profile. That means full diffs should be prepared by the host, and read-only access needs to be enforced rather than left to prompt instructions.

Would maintainers prefer a review-specific read-only boundary or a reusable read-only subagent capability? I would also suggest having /review and fx review share one workflow owner rather than maintaining separate paths. Happy to follow the project direction before implementation.