`flow` brings a drifting pull up to date with one action, once the drift list is on main #10959

MCP flow with { kind: "drift", repo, pull, action: "update" } now does what POST /{repo}/pulls/{number}/update does, as a writer of the repository. It calls the same bringUpToDate and answers { updating: "owner/repo!N", by: "<agent>" }.

The new test, the mcp-size and mcp-table tests and tsc --noEmit pass, and scripts/gate.ts printed nothing. I did not run keep_plan, so the plan is not kept on the issue. The fast suite (31 files) had one failure, the stale flow row in the MCP.md table, which I regenerated; I re-ran only mcp-table and mcp-size afterwards, not the full 31.

• Refusals:

- Someone who cannot write gets "Only someone who can write here brings a pull up to date." - A closed pull, a pull with no agent, or a pull whose tries are used gets the route's one message ("The crew could not take it now (closed, no agent, or it has already tried its limit); say what to do on the pull."). bringUpToDate returns the same undefined for all three, so I kept them as one message rather than guess apart. - A missing pull answers no_such_pull.

• Read-only tokens: the update counts as a write, so a read-only token cannot do it.
• Schema change: action in the flow schema is now untyped, because fleet operations send an object and the update sends a string. flow stays inside the size ceilings, and I raised none.
• Files: src/http/mcp/tools/flow.ts has the change. docs/MCP.md names the action and has the regenerated table row. test/mcp-flow-drift-update.test.ts drives a pull through the update, the closed, no-agent and tries-used refusals, the non-writer, a read-only token and a missing pull.

I did not add a way to list or pick which drifting pulls to update; kind: drift already lists them.

To try it, call flow with { kind: "drift" }, then { kind: "drift", repo: "alice/notes", pull: N, action: "update" } on one of the pulls listed.

Closes #10909

MCP flow with { kind: "drift", repo, pull, action: "update" } now does what POST /{repo}/pulls/{number}/update does, as a writer of the repository. It calls the same bringUpToDate and answers { updating: "owner/repo!N", by: "<agent>" }.

The new test, the mcp-size and mcp-table tests and tsc --noEmit pass, and scripts/gate.ts printed nothing. I did not run keep_plan, so the plan is not kept on the issue. The fast suite (31 files) had one failure, the stale flow row in the MCP.md table, which I regenerated; I re-ran only mcp-table and mcp-size afterwards, not the full 31.

• Refusals:

- Someone who cannot write gets "Only someone who can write here brings a pull up to date." - A closed pull, a pull with no agent, or a pull whose tries are used gets the route's one message ("The crew could not take it now (closed, no agent, or it has already tried its limit); say what to do on the pull."). bringUpToDate returns the same undefined for all three, so I kept them as one message rather than guess apart. - A missing pull answers no_such_pull.

• Read-only tokens: the update counts as a write, so a read-only token cannot do it.
• Schema change: action in the flow schema is now untyped, because fleet operations send an object and the update sends a string. flow stays inside the size ceilings, and I raised none.
• Files: src/http/mcp/tools/flow.ts has the change. docs/MCP.md names the action and has the regenerated table row. test/mcp-flow-drift-update.test.ts drives a pull through the update, the closed, no-agent and tries-used refusals, the non-writer, a read-only token and a missing pull.

I did not add a way to list or pick which drifting pulls to update; kind: drift already lists them.

To try it, call flow with { kind: "drift" }, then { kind: "drift", repo: "alice/notes", pull: N, action: "update" } on one of the pulls listed.