mergePull refuses a green checked against an older base when requireChecks is set (after #2028) #2315

mergePull now returns checks_required when the repo sets requireChecks and the pull's green was checked against an older tip of the base. Because the check is in mergePull, the API and MCP merges get it too. The new test and the existing stale-check and pull-mergeable tests pass, and tsc --noEmit is clean. I did not run the whole suite. I also didn't run the new test without the fix to confirm it fails.

• The gate: checksHold(check, baseTip) is new in src/checks/stale.ts; it holds only when the check is ok and not checkStale. mergePull in src/core/pulls.ts uses it with the live base tip, read inside the merge. A run that recorded no base, or a base that can't be read, still counts as not stale, as on the page.
• Test: test/merge-stale-green.test.ts goes through POST …/pulls/:n/merge. It records a green run against the old base, moves main, and expects a 409 checks_required. It then re-bases the green onto the current tip and expects the merge to land. A unit test covers checksHold.
• Not done: the early check on the sealedFrom path (a pull sealed in a separate repo directory) still looks only at the check's state. The final gate in mergePull covers it, since every landing passes through it.
• Test setup: the test turns on require_checks straight in the database, because the PATCH settings route returned 403 for the test's token.

Closes #2290

mergePull now returns checks_required when the repo sets requireChecks and the pull's green was checked against an older tip of the base. Because the check is in mergePull, the API and MCP merges get it too. The new test and the existing stale-check and pull-mergeable tests pass, and tsc --noEmit is clean. I did not run the whole suite. I also didn't run the new test without the fix to confirm it fails.

• The gate: checksHold(check, baseTip) is new in src/checks/stale.ts; it holds only when the check is ok and not checkStale. mergePull in src/core/pulls.ts uses it with the live base tip, read inside the merge. A run that recorded no base, or a base that can't be read, still counts as not stale, as on the page.
• Test: test/merge-stale-green.test.ts goes through POST …/pulls/:n/merge. It records a green run against the old base, moves main, and expects a 409 checks_required. It then re-bases the green onto the current tip and expects the merge to land. A unit test covers checksHold.
• Not done: the early check on the sealedFrom path (a pull sealed in a separate repo directory) still looks only at the check's state. The final gate in mergePull covers it, since every landing passes through it.
• Test setup: the test turns on require_checks straight in the database, because the PATCH settings route returned 403 for the test's token.

mergePull now returns checks_required when the repo sets requireChecks and the pull's green was checked against an older tip of the base. Because the check is in mergePull, API and MCP merges get it as well as the page and terminal. tsc --noEmit is clean and 16 tests pass across the new test and the stale-check and mergeable tests; I did not run the whole suite.

• Merge with main: main had added its own checksHold(requireChecks, state, stale) in src/checks/stale.ts, which the page and terminal already use. I kept main's version and dropped mine, so there is one answer for "does require_checks hold this back".
• The gate: mergePull in src/core/pulls.ts calls that function, reading the live head's check and the live base tip inside the merge.
• Test: test/merge-stale-green.test.ts goes through POST …/pulls/:n/merge. It records a green run against the old base, moves main, and expects a 409 checks_required. It then re-bases the green onto the current tip and expects the merge to land. I dropped my unit test for the old checksHold, since main's tests cover the new one.
• Not done: the early check on the sealedFrom path still looks only at the check's state. The final gate covers it, since every landing passes through it.
• Test setup: the test turns on require_checks directly in the database, because the settings PATCH returned 403 for the test's token.