Add a deterministic PullRequest workflow effect

[taras]

Story

As a workflow author, I want PullRequest to create or reconcile one pull request for an explicitly pushed branch, so review operates on known remote state without hiding a push inside pull-request creation.

Contract

PullRequest uses the contextual Repository and Git-host provider. title is required, number defaults to undefined, base defaults to the Repository's recorded initial branch, draft defaults to false, and rendered children form the body.

The contextual Repository's current named branch is the pull request head. PullRequest never commits or pushes, and direct remote observation is not a substitute for authorization to create or update one: the run must already hold a compatible Git.Push result from #370 for the same Repository identity, head branch, full destination ref and head SHA. A missing, conflicting or unreadable Push result fails before pull-request creation or update is observed.

PullRequest is an upsert over one explicit pull-request identity. When number is undefined, the effect creates a pull request for the current head and base; if an interrupted earlier attempt already created that same request, the compatible remote pull request is adopted instead of duplicated. When number is present, the effect updates that exact pull request's mutable fields to the requested title, body, draft state and base; its existing head must already be the current head, and if those fields already match, it records a no-op result. A supplied number whose existing pull request belongs to another Repository, head or base is a conflict rather than a rewrite to unrelated state.

The effect derives stable identity from the WorkflowRun and expansion and reconciles through #297. Its natural key identifies either the supplied Repository pull-request number or, when no number was supplied, the Repository's creation request for that head branch and base branch; the complete request fingerprint still discriminates title, body, draft and number changes.

The first production as result is stable creation/update evidence, not a live pull-request snapshot. It includes the filtered Repository identity, the provider's stable pull-request identity, number, URL, state, head SHA and base SHA. Reviews, comments, checks, labels, reviewers, merge state and later title, body, draft or branch movement are separate reads or effects rather than freshness embedded in the creation result.

Provider-specific payloads, credentials and host-local paths do not leak into the public component contract or filtered history.

Acceptance

• PullRequest performs no implicit commit or push.
• PullRequest requires retained compatible pushed-head evidence for the same Repository identity, head branch, destination ref and head SHA.
• A missing, conflicting or unreadable Push result fails before pull-request creation or update is observed.
• With no number, PullRequest creates one pull request for the current head and base, or adopts a compatible creation left by an interrupted earlier attempt.
• With a number, PullRequest updates that exact pull request's title, body, draft state and base when its existing head is the current head.
• With a number and no requested field changes, PullRequest records a no-op result.
• A supplied number for another Repository, head or base is a conflict rather than an unrelated rewrite.
• Replay cannot create a duplicate pull request.
• Existing compatible state resolves to the same pull request.
• Conflicting head, base, repository, or pull-request state is diagnosed.
• Interruption after remote creation or update reconciles by provider observation.
• The result identifies the exact head and base SHA and remains valid as the recorded creation/update outcome.
• The public as value is structured creation/update evidence, not only a URL and not a live freshness snapshot.
• Review verdicts bind to the head SHA they actually inspect.
• Provider-specific payloads do not leak into the public component contract.

Dependencies

• Add a deterministic Git.Push workflow effect #370 supplies explicit remote branch publication and pushed-head evidence.
• Add shared external Git-host effect reconciliation #297 supplies shared Git-host effect reconciliation.
• End goal: ✨ Compose and certify the supervised adversarial implementation workflow #181.