fix(webhooks): poll GitHub's live test merge every 2s and build our own when it is unreachable

The probe now runs immediately, then every two seconds up to a bounded
budget, and accepts a merge as soon as its second parent is the payload
head — including when the API has already moved to a newer head, which is
the measured rapid-push race. A first parent older than the API's base is
logged, not rejected: GitHub freezes a head's merge when only the base
moves and its own run for the push used that commit.

When no merge of the payload head can be resolved, the engine builds
merge(current base tip, payload head) with the merge builder and serves
the run from its own mirror, with a warning. The bare
`refs/pull/{n}/head` fallback is gone.

Author: Bnjoroge1

CHANGELOG.md

@@ -62,14 +62,12 @@ Releases before v0.27.0 predate the changelog.
   the runner itself, and the official runner's Docker command shape are
   unchanged.
 
-- **A burst of pull-request deliveries no longer parks the webhook worker
-  pool in merge-state polling**: a delivery whose payload head is no longer
-  the pull request's current head falls back after a single probe instead of
-  re-polling a merge that cannot be produced, at most half the worker pool may
-  be waiting on GitHub's mergeability computation at once (a delivery that
-  cannot claim a slot falls back to `refs/pull/{n}/head` rather than holding a
-  worker), and a fork delivery the fork-workflow policy will skip spends no
-  GitHub calls on a merge nothing will run.
+- **Fresh pull-request merge resolution**: Webhook-delivered `pull_request` and
+  `pull_request_review` runs poll for GitHub's live test merge and accept it
+  only when its second parent matches the payload head. If unavailable, the
+  engine builds a merge of the current base and pinned payload head and serves
+  it from its mirror; it never falls back to the bare pull-request head.
+  Conflicted pull requests do not start `pull_request` runs.
 
 - **Server integration tests no longer fail on a leaked static PAT**:
   `cargo test` shares one process environment across a whole test binary, so