Support checkpoint discovery/propagation for PRs from forks

[ishaan812]

Problem or use case

When contributors open PRs from a fork (for example, ishaanshah812/cli -> entireio/cli), commit trailers like Entire-Checkpoint: <id> can reference metadata that exists only in the fork's entire/checkpoints/v1 branch.
In upstream review, maintainers may not be able to resolve those checkpoint IDs unless extra manual sync steps are taken. This breaks the expected "review with checkpoint context" workflow and is particularly painful for OSS contribution flows.

Real example: PR #406 discovered this issue while making the PR.

Desired behavior

Fork-based PRs should preserve checkpoint reviewability in upstream without requiring contributors to manually create extra checkpoint-sync PRs.

Ideal outcome:

- Contributor opens PR from fork with commits containing `Entire-Checkpoint` trailers.
- Upstream maintainers can resolve checkpoint metadata for referenced IDs during review.
- Metadata is either available directly or can be synced/retrieved through a first-class workflow.

---

Proposed solution

Possible approaches (with tradeoffs):

1. Entire GitHub App (best UX)

   • Detect checkpoint IDs in fork PRs.
   • Sync required metadata to upstream entire/checkpoints/v1 (or equivalent), potentially via managed PR automation.
   • Tradeoff: requires installing and trusting an Entire-managed app.

2. GitHub Action sync workflow

   • Repository workflow syncs checkpoint metadata from fork context when PRs are opened/updated/merged.
   • Tradeoff: manual setup, added maintenance burden, and uses repo compute.

3. Fallback lookup across remotes

   • If checkpoint ID is not found in upstream, attempt resolution from PR head/fork remote.
   • Tradeoff: metadata availability depends on fork/branch lifecycle; auth/permissions can be complex.

A hybrid may be best: fallback lookup for immediate usability plus optional sync for durable storage in upstream metadata.

Alternatives or workarounds

Current workaround is manual and not scalable:

• Open separate PR(s) to propagate checkpoint metadata into upstream.
• Or maintainers manually fetch from fork refs.

Both increase process overhead and make open-source contributions harder than necessary.