fix(workspace): fetch PR refs from upstream and pin applied commit (audit #3)

[sbalabanov]

Summary

Workers cloned with --local had their origin pointing at the pool's local directory (no pull/* refs), and Apply diffed against the floating PR head instead of the pinned commit -- allowing cache key collisions when the PR advanced.

• Thread the upstream remote URL from the orchestrator through to gitRequest.Apply so PR refs are fetched from the real remote, not the worker's local origin
• Pin content by diffing baseRef...commit instead of baseRef...pull/<id>/head; retain the ancestor check as a sanity guard
• Make commit required at validation (mapper.ProtoToBuildDescription) since it forms cache identity
• Add real-git integration tests: stable tree across PR advancement, upstream fetch from local clone, stale commit rejection

Test plan

• All existing unit tests pass with updated signatures
• New mock-based tests verify upstream fetch and commit pinning
• New real-git tests with a local bare repo verify stable treehash across PR advancement
• go build ./... and go test ./... pass (excluding env-gated integration tests)
• make gazelle regenerated BUILD files

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sbalabanov]

Github pull request which comes from upstream is supposed to be immutable - i.e. not only it contains a traditional Github URL in a form of #257, but also a commit hash of the head of the request, so advancement in a PR causes a request to be revalidated. Analyze the fix in the light of that, specifically analyze how the request URL is parsed. Is the fix needed?
Reply to this comment, keep the PR in draft mode.

[sbalabanov]

Thanks for calling this out. I traced the request construction and application path against the immutable (PR URL, head commit) contract.

workspace.NewRequest parses the URL with net/url, accepts the normalized github://... scheme, and passes only u.Path onward. NewGitRequest then uses filepath.Base(requestPath), so the URL contributes only the PR number to Apply; it does not pin the applied Git object, and its repository/remote components are discarded.

The commit therefore has to provide the immutable content identity. Before this PR, Apply fetched the floating pull/<id>/head, checked only that the supplied commit was an ancestor, and then diffed against the floating head. If the PR advanced, an already-issued request for the older (URL, commit) still passed the ancestor check but materialized the newer head. Upstream revalidation creates a new request/cache key, but it does not change the semantics of that older or in-flight request. Diffing baseRef...commit is consequently still needed.

The upstream-fetch part is also needed independently: worker clones have origin set to the pool's intermediate local clone, which does not expose GitHub pull/* refs. Because URL parsing currently discards the repository location, this change threads the already-authoritative build remote to the fetch. The commit-presence/ancestor check remains only a provenance guard; the requested commit is the content actually applied.

No additional code change was needed from this analysis; the reviewed implementation remains at ac28100c69e58e524f0e5a70c7f3a16659c16286. I have kept the PR in draft as requested.

[addressed by agent]

[sbalabanov]

closing in favor of #264 and subsequent implementations