An approved pull says when it will land #10879

An approved, open pull's page now shows one line under its path, such as "first in the queue: lands in about 15 min". The pull MCP tool returns the same thing as eta: { minutes, says }, and eta is null when the pull isn't approved and open.

• Estimate: src/flow/landing_line.ts is new and reads the rows once for both the page and the tool. A pull's place in the queue is its rank among the repo's open approved pulls, earliest approval first. An approval stops counting once a later changes-requested review arrives. The pace is the repo's landings in the last hour. With none, it falls back to the median of finished merge-queue gates over 6 h.
• Where it shows: the page line is rendered in changeHead (src/web/studio/change.ts) only on the main pull page, not on the Files and conflicts tabs. The tool's eta is in src/http/mcp/tools/pull.ts, as a field on the existing tool, not a new tool.
• Unreached list: src/flow/landing_eta.ts is out of scripts/unreached-allow.json.
• Tests: test/landing-line.test.ts has an unapproved pull (no line, eta null) and a fixed 14-minute gate with nothing landed. That gives the line "first in the queue: lands in about 15 min" on the page and eta of { minutes: 14, says: … } from the tool.
• Checks run: the new test, test/mcp-size.test.ts and test/flow-landing-eta.test.ts pass, as do bun x tsc --noEmit, scripts/gate.ts and scripts/design-lint.ts. scripts/fast.ts said the diff was too broad to name tests (exit 2), so I ran only those three test files.
• Push: the pre-push hook wanted a "Try:" commit message, so there is an empty "Try:" commit at the end.
• Left out: the line does not account for pulls currently at the gate or for red gates beyond what the observed pace already includes. The feed and pulls list don't show it. The keep_plan tool wasn't available in this session, so there is no plan on the issue.

To try it, approve an open pull and open its page.

Closes #10860

An approved, open pull's page now shows one line under its path, such as "first in the queue: lands in about 15 min". The pull MCP tool returns the same thing as eta: { minutes, says }, and eta is null when the pull isn't approved and open.

• Estimate: src/flow/landing_line.ts is new and reads the rows once for both the page and the tool. A pull's place in the queue is its rank among the repo's open approved pulls, earliest approval first. An approval stops counting once a later changes-requested review arrives. The pace is the repo's landings in the last hour. With none, it falls back to the median of finished merge-queue gates over 6 h.
• Where it shows: the page line is rendered in changeHead (src/web/studio/change.ts) only on the main pull page, not on the Files and conflicts tabs. The tool's eta is in src/http/mcp/tools/pull.ts, as a field on the existing tool, not a new tool.
• Unreached list: src/flow/landing_eta.ts is out of scripts/unreached-allow.json.
• Tests: test/landing-line.test.ts has an unapproved pull (no line, eta null) and a fixed 14-minute gate with nothing landed. That gives the line "first in the queue: lands in about 15 min" on the page and eta of { minutes: 14, says: … } from the tool.
• Checks run: the new test, test/mcp-size.test.ts and test/flow-landing-eta.test.ts pass, as do bun x tsc --noEmit, scripts/gate.ts and scripts/design-lint.ts. scripts/fast.ts said the diff was too broad to name tests (exit 2), so I ran only those three test files.
• Push: the pre-push hook wanted a "Try:" commit message, so there is an empty "Try:" commit at the end.
• Left out: the line does not account for pulls currently at the gate or for red gates beyond what the observed pace already includes. The feed and pulls list don't show it. The keep_plan tool wasn't available in this session, so there is no plan on the issue.

To try it, approve an open pull and open its page.

An approved open pull now says where it stands in the landing queue and roughly when it will land, on its page and in the MCP pull tool. The line reads "first in the queue" or "number N in the queue", followed by the estimate. The tool returns it as eta: { minutes, says }, null unless the pull is open and approved.

The check had failed on three tests, and I fixed one cause:

• Pull-page SQL budget: the landing line adds one statement to the pull page, so test/pages-budget.test.ts went from 109 to 110 for /:owner/:name/pulls/:number. I raised the budget to match. This is a budget change, not a test that was wrong.
• The other two failures: the blob-switch test in test/media.test.ts and the tui-system test passed when I ran them alone, so I changed nothing for them. I don't have a cause for those two failures. Rerun them if they come back red.

The gate script, tsc --noEmit, and the four test files I reran (pages-budget, landing-line, media, tui-system) all pass locally.

To try it, open an approved pull and read the line under its path, or call the pull tool and look at eta.

The new logic is in src/flow/landing_line.ts, with tests in test/landing-line.test.ts.

An approved open pull now says when it will land on its page, in the pull tool (as eta: { minutes, says }) and in the terminal pull screen. The terminal screen and the new docs page are what the review asked for. The gate script, tsc --noEmit and the pull-screen, landing-line and tui-pull-* tests pass locally; I did not rerun the full suite.

• Terminal: the pull screen's header line shows the same words after the step, for example · first in the queue: lands in about 15 min. It calls landingLine, the same reader as the page and the tool. It is not shown for a mirrored repository. test/tui-pull-landing.test.ts checks that the line is absent before approval and present after. I did not run it against the code without the line.
• Docs: docs/features/landing-line.md covers where the line shows and how place and pace are read.
• Test cleanup: I fixed the copied step-surfaces temp-dir prefix and removed the stray double blank line in test/landing-line.test.ts.
• Budget: the pull-page SQL budget is still one statement higher (110), as the review accepted.

The terminal line sits in an already long header, so on a narrow terminal it can be clipped. I put it before next: so it survives longer than that.