t3_thread_read repeats every linked PR in each call and doesn't show PR watch state #25642

What happened

t3_thread_read (and t3_thread_list) return the thread's entire pullRequests list in every call. On a long-lived dispatcher thread that links each PR it handles, that is 164 links (152 open) on mcp:launch:870f4a9a-16a6-4ff8-a844-a7c824708e01:orchestrator-prlabels-v1, about 8 KB repeated at the top of every page read. The PR dispatcher's audit of its own 12,256-item thread had to split reading across three agents partly because of it.

The list also says nothing about watches. Each entry has host, repository, number, url, source and state, but not whether a PR watch is active, so a parent can't tell a child that's waiting on its PR watch from one that has stalled. A dispatcher runbook told agents to read pullRequests[].watch, which doesn't exist (friction 2026-10-21 09:48Z).

Expected

• t3_thread_read doesn't repeat the full PR list on every page: omit it unless asked (e.g. include: ["pullRequests"]), cap it, or return only open PRs plus a count. list_thread_pull_requests already exists for the full list.
• Each PR entry includes its watch state (watching / not watching, and since when).

Where

apps/server/src/mcp/OrchestratorMcpService.ts:840-851 threadPullRequests, used by listItemFromShell (:870) and threadDetail (:904), origin/main fe507c5a1e.

Related: https://git.cafe/pingdotgg/t3code/issues/21578 (long threads are slow).