spike(github): validate public fork PR Checks and trust isolation

[back1ash]

Summary

Build a minimal disposable proof of concept to determine whether a GitHub App can reliably analyze public fork pull requests and publish an isolated Check against the intended PR and test-merge commit without trusting or executing contributor-controlled content.

Scope

• Test minimum installation-token permissions and repository-content access.
• Fetch base, head, and test-merge content by immutable commit identity.
• Create, update, complete, and rerequest a Check Run.
• Exercise same-repository PR, public fork with and without App installation, first-time contributor approval, base-branch updates, deleted head branches, unreadable heads, and duplicate deliveries.
• Exercise multiple PRs that share the same head SHA and prove that one PR's success cannot satisfy another PR's required gate.
• Verify that trusted configuration comes from the base repository and cannot be weakened by fork content.
• Record webhook payloads, permission behavior, API constraints, idempotency requirements, and failure modes.

Acceptance criteria

• A reproducible matrix records expected and observed results for every scenario.
• Each Check is associated with the exact repository, PR, base SHA, head SHA, and test-merge SHA being analyzed.
• Base updates and synchronized PRs cannot reuse or misattribute stale success.
• Same-head-SHA PRs remain isolated.
• No contributor-controlled code is executed and no fork input can alter credentials, trusted policy, or report destinations.
• Tokens are not exposed to fork code, logs, or reports.
• Content access is read-only and pinned to immutable revisions.
• Duplicate delivery and rerequest behavior is demonstrated or its required design is documented.
• Unsupported cases and GitHub constraints are documented.
• The spike concludes with a feasibility recommendation and explicit P0 scope fallback.

Dependencies

• A test GitHub App with candidate minimum permissions.
• Public test repository and external fork.
• Representative OpenAPI fixture.
• Initial trust-boundary assumptions from the threat model.

Non-goals

• Production webhook, queue, worker, or report implementation.
• Private-repository support.
• Executing builds, tests, or arbitrary repository code.
• Selecting a production hosting provider.