Model first-party pull request synchronization builds

[sj26]

Why

Buildkite's GitHub integration coalesces first-party pull_request.synchronize deliveries into linked push builds enriched with pull request metadata. buildkite-gha treated BUILDKITE_GITHUB_EVENT=push as authoritative, so a workflow with filtered push and pull_request triggers selected the push context and rejected the feature branch. Rebuilds without linked push metadata selected the pull request context instead, producing inconsistent results.

This was reproduced by sj26/mailcatcher Buildkite build #31.

What

• Model a GitHub push with a positive Buildkite pull request number as one pull_request/synchronize event using trusted Buildkite head and base metadata.
• Keep ordinary branch pushes as push, partition generated conditions so the event groups cannot overlap, and preserve Buildkite repository, commit, and checkout authority.
• Treat the linked push payload as insufficient pull request path-filter evidence, so those filters fail closed.
• Cover linked-webhook and rebuild paths with focused event, trigger, path-filter, and plugin integration tests, and document the compatibility and security boundaries.