feat(mobile): review proposed plans from the phone

[tusharbhardwaj-bk]

Problem

Mobile had no way to act on a proposed plan at all. The thread showed a "Plan Ready" pill and the only way forward was finding a desktop — there was no plan affordance anywhere in apps/mobile.

What this adds

A native plan-review surface reachable from the thread screen: read the plan, question specific lines, then approve or request changes.

Web reviews plans in a Plate rich-text editor, which does not port to a phone. The operations that matter on a phone are read, question, and decide — so this surface is read-plus-annotate, and reviewer edits to the plan body stay a desktop affordance. editedMarkdown is always null on submit, which PlanReviewSubmitInput already allows.

• Selection copies the diff reviewer's gesture exactly (tap to anchor, tap to extend, tap again to clear), so reviewers moving between the two surfaces don't learn two interactions.
• Anchoring is by quoted text, re-located against whichever version is on screen via the existing locateQuotedLineRange. A quote the agent has since rewritten is still listed as unanchored rather than silently dropped or pinned to the wrong paragraph.
• The subscription supersedes the one-shot read, same precedence as PlanReviewPanel, so the screen doesn't go stale when the agent revises the plan or another client comments.
• Reverse states are covered: comments resolve and reopen, selection clears, the banner disappears with the decision.

Fork-cost notes

Two upstream-owned files are touched, one marked line each:

• ThreadRouteScreen.tsx — one import, one element. PlanReviewThreadBanner resolves its own capability, documents and visibility and returns null when inapplicable, so no conditional leaks into the upstream render.
• Stack.tsx — one route pair, reusing the diff-review composer's Android formSheet workaround.

planReviewMarkdown moved from apps/web/src/components/planreview/ into packages/client-runtime/src/state/ rather than being copied — it was already DOM-free and both clients need it, following the pattern set by a768835 for the phase sidebar. Git tracked it as a rename, so history follows.

The fork-marker baseline shrank (169 → 168): marking the Stack.tsx edit made that file fully compliant, and the checker requires removing it so the ratchet cannot loosen again.

Verification

• 31 new tests across the three pure modules (planReviewAvailability, planReviewDocumentModel, planReviewSelection), all in fork-owned files so they prove the feature survived the next upstream merge.
• tsc --noEmit clean: mobile, web, client-runtime, shared.
• vp lint clean on the new scope.
• scripts/check-fork-markers.ts passes.

No screenshots: I have not exercised this on a simulator. It is behind the planReview capability, so it stays invisible on any server that does not advertise it.

Model: Claude Opus 5 (1M context), harness: Claude Code in T3 Code.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Merged expbkmain in, resolving one relocation conflict

This branch also carries two commits that predated my work (a768835c4 phase-sidebar sharing, d14436353 branded mobile build) — no other open PR claims them, so this PR is their delivery path.

Merging expbkmain hit one conflict in PhaseGroupedSidebar.logic.ts, and it is the relocation hazard AGENTS.md calls the most dangerous kind rather than an ordinary content conflict:

• a768835c4 (ours) moved that logic into @t3tools/client-runtime/state/phase-sidebar, leaving the Tailwind class-name helpers plus an export *.
• 317f7ce47 (theirs, on expbkmain) added to the same block in place.

Taking ours drops the Mattermost feature; taking theirs re-duplicates logic that now lives in client-runtime. Resolution: keep the relocation and port their two additions into the module the logic moved to — PhaseSidebarMattermostLink + resolvePhaseSidebarMattermostLink, and mattermostLinkSupported on PhaseSidebarRow.

I verified those were the only things expbkmain added to the block two ways: diffing its export set against the relocated copy, and reading every hunk in that file since the merge base. apps/web needed no change — the existing export * means PhaseGroupedSidebar.tsx imports both symbols from exactly the same path as before.

Evidence the port is behaviourally correct: MattermostThreadBadge.test.tsx imports resolvePhaseSidebarMattermostLink through the web re-export path and its 6 tests pass unchanged.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	13.6 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	7.2 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.7 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	11	—	21	✅
Claude	Total thread wire	—	13.6 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	7.2 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	11	—	21	✅

Baseline: unavailable · PR result: c942439 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 110.4 KiB
• Claude decoded thread snapshot: 111.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.