Add shared external Git-host effect reconciliation #297

Story

As a workflow host implementor, I want one reconciliation contract for Git-host mutations, so Git push, pull-request creation, and issue creation do not invent separate replay policies or duplicate uncertain external effects.

Contract

A Git host is an external service that owns remote Git repositories and associated collaboration objects such as branches, pull requests, and issues. GitHub is one Git-host adapter. A Git host is distinct from the local Git capability and the trusted workflow host.

This contract covers exactly three Git-host effect kinds: git-push (#370), pull-request (#295), and issue (#296). Prompt is not one of them and keeps its Agent-provider contract.

An external effect derives stable identity from the WorkflowRun and expansion. It records filtered inputs, pre-state, observations, decision, and result locally, but does not claim a transaction across SQLite and the provider.

On first execution or resumption:

1. observe provider state using the stable identity and effect-specific natural keys;
2. adopt proven compatible completion;
3. perform proven absence;
4. reject conflict or permanent ambiguity; and
5. let explicit middleware retry or suspend temporary unavailability.

The Git-host provider is contextual and provider-neutral. GitHub is the first adapter, not a type in shared component contracts.

A provider need not implement every kind. A plain Git server may support git-push and refuse pull requests and issues; it refuses from observation, before any remote work, and the boundary neither performs nor records anything. There is no capability discovery and no negotiation.

Routing is one request-only contextual operation that carries no completion authority. Public middleware receives one frozen, one-use routing request, may inspect, refuse, narrow, or delegate it, and its return is ignored; it receives no credential, no capability, and no provider-only phase evidence. Only an answer accepted by the invocation's own private terminal — reachable solely through the continuation the selected provider's handler holds — can author a durable outcome. Two public surfaces that each look harmless must never combine into completion authority.

Acceptance

• Add a deterministic Git.Push workflow effect #370, Add a deterministic PullRequest workflow effect #295, and Add provider-neutral Issue read and upsert workflow effects #296 use the same reconciliation state machine.
• Replaying a recorded completion performs no provider mutation.
• Interruption after remote success but before local result publication adopts only provably compatible state.
• Conflicting external state is diagnosed rather than silently overwritten or duplicated.
• Inputs, pre-state, observations, decision, and filtered result are durable.
• Temporary unavailability is distinguishable from proven absence and permanent ambiguity.
• Credentials and raw provider payloads do not bypass the journal security boundary.
• Shared production code uses contextual Git-host APIs and contains no GitHub runtime coupling.
• One repository-controlled component wrapping every exposed Git-host middleware hook, at every supported priority, cannot publish a forged result; the selected provider is invoked exactly once and its result is the sole retained outcome.
• A provider may support only a subset of the three kinds.

Dependencies

• Add contextual workflow runs with pinned commits #289 supplies run and expansion identity.
• Store WorkflowRuns and filtered journals in SQLite #291 supplies the filtered durable journal.
• Add workflow inspection, cancellation, suspension, and deletion #367 supplies suspension and lifecycle ownership.
• End goal: ✨ Compose and certify the supervised adversarial implementation workflow #181.