fix(webhooks): resolve fresh pull request merge commits
Flow 3 of the pull-request test-merge design. Webhook deliveries probe GitHub immediately, then every 2 seconds for up to 30 seconds. A GitHub merge is accepted only when its first parent matches the base SHA returned by the same API response and its second parent matches the exact webhook payload head. Stale-base candidates are rejected and polling continues; matching-head conflicts skip pull_request runs.
If GitHub does not offer that exact merge within the polling budget, the API fails, or the delivery loses the head race, the engine builds merge(base fetched from the target branch at fallback time, payload head). Runs check out that merge from the engine-served repository; there is no bare pull-request-head fallback. Workflow discovery remains pinned to the payload head. The base is not guaranteed to remain latest at job execution, and base advancement does not trigger automatic reruns. pull_request_target, fork policy, and local runs retain their existing behavior.
Stacked on #431 at A1 head b1abd823; no new dependency or lockfile change is included.
Validation: the original stale-base acceptance test passed against the unmodified PR head. After the fix, the stale-base rejection/re-poll/fallback test passed and performed a real Git fetch of refs/pull/42/merge from the engine-served snapshot followed by checkout; the matching-parent acceptance test also passed. just test-ci passed fmt, clippy, zizmor, and other suites, but the server library suite consistently failed the unrelated config::tests::round_trips_github_and_secrets on macOS with store envelope authentication failed (also with PRELOOP_CREDENTIAL_STORE=file). just dogfood built the server but stopped before runner startup because its temporary control database was not migrated. No VM checkout is claimed; the prior runner smoke was blocked at SmolVM krun_start_enter -22.