The pull API and the MCP say whether a pull merges: `mergeable` and `conflicts` on every reading of a pull #1413

Part of #586 (P0 Trust), the first piece of #1177. pullStatus (src/core/pulls.ts) already computes mergeable and conflicts with git merge-tree --write-tree (src/git/merge.ts), and the pull page and studio already read it. The JSON API and the MCP do not.

Done looks like.

• [ ] GET …/pulls/N and the pull list carry mergeable (boolean) and conflicts (paths) for open pulls, computed against the base's current head and cached by head:base oids so a list stays fast.
• [ ] The MCP's reading of a pull carries the same two fields.
• [ ] Tests: a pull made to conflict reads mergeable: false with the path; after the base moves to resolve it, mergeable: true and conflicts: [].
• [ ] A new test file is added to GATE in scripts/gate.ts in the same push (bun test test/check-list.test.ts is green); the last two tries went red on exactly this.
• [ ] If the check goes red on a test this change does not touch, the pull names that test and why it is unrelated; it does not widen the change to fix it.

Files. src/http/api.ts, src/http/mcp.ts, src/core/pulls.ts, and one new test file.

Parked by the crew: the check failed ("the gate's list > every test/*.test.ts is in exactly one list, and every entry exists") and the decider saw no point in another try (pull #1415 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.