fix(ci): stop trusting refs/pull/N/merge for triggered-integration-test

[jordigilh]

Fixes #66

Problem

resolve-source's "Verify PR merge checkout" step compares the checked-out merge commit's parents against a live-resolved base_sha (fixed in #62), but the checked-out commit itself still came from GitHub's refs/pull/<n>/merge -- a commit GitHub computes and caches asynchronously.

Per GitHub's own changelog, Changes to test merge commit generation for pull requests (2026-02-19), that ref is only regenerated on a push to the PR branch, a merge-base change, or a 12h max-age timer -- and viewing the PR page no longer forces a refresh.

Live reproduction against PR #63, right after #62 merged: refs/pull/63/merge stayed stale for 49+ minutes (including after an explicit mergeable recheck that returned true), which would fail "Verify PR merge checkout" with a "base changed" error for a transient, unrelated-to-the-PR reason. Full writeup and evidence in #66.

Fix

Stop depending on refs/pull/N/merge entirely. resolve-source already resolves head_sha (PR API) and base_sha (live refs/heads/main) as two pinned commit SHAs -- construct the merge locally from those with git merge --no-ff instead, in both:

• resolve-source's "Resolve source" step, to fail fast on a real conflict before the 120-minute glb-e2e job runs, and
• glb-e2e's new "Reconstruct PR merge" step, to get the actual tested tree.

Pinning author/committer identity and date (new MERGE_COMMIT_* workflow-level env vars) makes the merge commit fully deterministic, so both jobs -- running on separate, stateless runners -- independently arrive at the identical SHA. fetch-depth for the shared checkout moves from 2 to 0 (full clone) since git merge needs enough history to find the true merge-base, which a shallow clone can't guarantee for a PR that's many commits behind main.

The checkout_sha output is new: actions/checkout's ref: now targets a real, always-fetchable commit (base_sha for a PR, main's tip otherwise) instead of a merge SHA that may not exist as a GitHub-side object yet; tested_sha keeps its existing meaning (the commit actually under test) and every downstream consumer (image provenance labels, the demo's own re-check, the summary table) is unchanged.

Validation

No permission to dispatch this workflow on either praxis-proxy/grid (not an admin) or a fork (GitHub doesn't register workflow_dispatch-only workflows added post-fork without manual UI activation) -- same platform constraint noted on #62/#65.

Instead, validated the exact logic live against production data:

• actionlint (which also runs shellcheck on the embedded scripts) is clean.
• Simulated resolve-source's new "Resolve source" logic in one directory, and glb-e2e's new "Checkout Grid at base revision" + "Reconstruct PR merge" logic in a separate, unrelated fresh clone (no shared git state, mirroring two independent GitHub Actions runners), both against real PR fix(crdt): cap distinct origin site-slots per tenant_spend counter #63 (base_sha=7ebabdbc.., head_sha=50720c9d..):

  JOB1 (resolve-source) tested_sha=6df4a70a435aa642e03f713be08e6cc857d4abad
  JOB2 (glb-e2e)         reconstructed HEAD=6df4a70a435aa642e03f713be08e6cc857d4abad
  MATCH: both jobs independently reconstruct the identical merge SHA
  PASS: all invariants hold (parent_count=2, parents == base_sha/head_sha)
  

• Confirmed the "main" (no PR number) path is untouched by this change.