The fast check cannot see a pull's commit messages, so the gate's Why-now rule always fails there #8882

The fast tier gives the check a history of two shallow commits (src/checks/history.ts, fetch --depth=1): the base and the check's own merge commit, whose message is only check of <sha> merged into main (src/checks/merged.ts). scripts/gate.ts whyNowRefusal reads git log $FORGE_CHECK_BASE..HEAD, so it sees that one message and never the pull's own commits. A pull adding a file under src/actions, src/web/pages, src/http/api, src/http/mcp/tools or src/tui fails the rule however its commits are worded; bun scripts/gate.ts passes in a full clone against the same base.

Seen on #8837 (f3cc6df: the tip commit had a Why now: line, the check still failed).

A fix: have mergeForCheck append the pull's own messages (git log -n 200 --format=%B base..head, capped) to the merge commit it writes, with a test in test/merged-check.test.ts that the merge commit carries them. Pipeline work (#5276).

Done when:

• [x] A pull whose commit says Why now: <reason> passes the fast tier's gate.
• [x] A test fails without the change.

Reviewed pull #8883 at its head: ticked A pull whose commit says Why now: <reason> passes the fast tier's gate.; A test fails without the change..