feat(review): compare local branch with remote

[leoreisdias]

Context

Review mode can compare a branch with its base or inspect selected working-tree states, but it does not have a direct way to answer: “What would I push to this branch’s configured remote?”

This adds a Local vs remote branch diff mode. It compares the current working tree with the branch’s configured remote-tracking ref from the last fetch, including local commits, staged and unstaged edits, and untracked files.

What Changed

• Adds Local vs remote branch to the review picker when the current branch has an upstream.
• Resolves the comparison from @{upstream} instead of assuming an origin/<branch> naming convention.
• Carries the new mode through diff generation, file expansion, staleness fingerprints, worktree parsing, immutable review snapshots, staging support, agent-review context, and feedback exports.
• Adds the option to Review settings while intentionally omitting it from first-run setup, where upstream availability is not known.
• Explains the comparison in the picker tooltip and provides a dedicated empty state when local and remote-tracking content match.

Review Focus

• The remote side intentionally uses the local remote-tracking ref. It does not fetch, so the comparison reflects the repository’s last fetched state.
• The tracked diff is <upstream> versus the working tree with no right-hand ref; untracked files are added separately, matching the composite behavior of the existing review modes.
• The main picker hides the option when @{upstream} cannot be resolved. Persisted defaults fall back through the existing initial-mode resolver when the option is unavailable.
• The first-run setup omits this option so unpublished branches cannot select a comparison that requires an upstream.

Screenshots

Review picker

Settings

Test Plan

• 224 focused tests across review-core, configuration, setup, feedback export, panel-view persistence, and agent-review instructions
• TypeScript checks for core, shared, AI, server, UI, guide viewer, guides.show, strict UI consumer, and Pi extension
• bun run build:review
• bun run build:hook
• git diff --check
• Manually exercised the mode against a branch with a configured remote-tracking branch

[backnotprop]

Thanks for the quick self-fixes; the review of this PR came back clean on everything that matters (both runtimes pick the mode up purely through the shared modules, the panel/diff coupling holds, the fingerprint invalidates on fetch, and the tests are genuinely good, including the bare-remote integration test).

One mechanical step left, and it is a timing artifact, not a mistake in your change: your manifest refresh commit ran before the merge of upstream main, and main's recent packages/ui work is in the portable viewer bundle graph, so the merge moved the bundle hash again and re-staled the freshly pinned manifest. CI now expects a manifest generated at your current head. Run:

bun run --cwd apps/guides-show build:viewer && bun run --cwd apps/guides-show sync:manifest

and commit the regenerated packages/core/guide-viewer-manifest.ts. That should be the last thing between this and merge.

For context on why your PR pays this toll at all: the review picker options live in packages/ui/config/settings.ts, which the guides.show read-only viewer also bundles, so any change there re-pins the viewer build. Nothing to fix on your side beyond the regen.

AI-assisted (Claude) under maintainer direction.

[backnotprop]

Merged. This was an unusually well-integrated contribution: the mode flows through both server runtimes purely via the shared modules, the panel coupling and staging invariants hold, and the bare-remote integration test is exactly the kind of coverage this repo wants. The since-fetch semantics and the first-run guard you added on your own initiative both matched what our review flagged. Ships in the next release.