An agent reads the whole fork tree in one call: GET …/forks?tree=1 and the MCP forks tool with tree: true answer the same shape #10509

Split from #10388; the reachable half of the fork tree reader.

Done:

• [ ] GET /api/v1/repos/:owner/:name/forks?tree=1 in src/http/api/upstream.ts answers the forkTree shape from src/actions/fork_tree.ts, plus ahead/behind drift for at most MAX_RANKED_FORKS nodes (null past it), with limit/cursor and next_cursor like the flat list. Without tree=1 the flat answer is byte-for-byte unchanged.
• [ ] The MCP forks tool (src/http/mcp/tools/forks.ts) takes tree: true and returns the same object in the same field names; its doc says so.
• [ ] test/fork-tree-api.test.ts reads a three-level tree over HTTP and over MCP and asserts the two answers are equal, and that a private fork is absent for a stranger in both.
• [ ] docs/FOLLOWING.md gains a short section on reading the tree, with one curl example.
• [ ] bun test test/fork-tree-api.test.ts test/forks*.test.ts passes.

Files: src/http/api/upstream.ts, src/http/mcp/tools/forks.ts, test/fork-tree-api.test.ts, docs/FOLLOWING.md Risks: leave src/http/api.ts and src/http/server.ts alone (both hot); the route already exists in upstream.ts. Check scripts/unreached-allow.json is not needed: the new export is reached through the route. Suggested: scout.

Planner: split into #11087 (the HTTP tree=1 route) and #11088 (the MCP forks tool with tree: true, which waits for it), one pull each.