[jacobecox]

Two fixes to the e2e CI (work item 5161), found on #664, the first PR that wasn't one of the onboarding PRs.

1. PRs were tested against an old main. plan and the coverage gate compared the PR with pull_request.base.sha, which is main as of when the PR was opened. Every test merged since then counted as part of the PR. #664 changed only timescaledb-highly-available, but CI ran 12 other templates for 35 minutes and went red on redis-cluster. Both workflows now compare against the first parent of the merge commit they check out, which is today's main.

• Simulated on timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484) #664's merge commit: before the fix 12 targets, after it 0. timescaledb-highly-available has no tests, so 0 is correct. The gate still prints ok.

2. Wait for every replica before running checks. After --wait, the runner polls get-deployments until every location has its desiredScale replicas, all of them ready, on two polls in a row. Locations scaled to zero and cron workloads are skipped. On #664, redis-cluster was reported ready while node 5 was still starting, the cluster formed after the checks gave up, and every cluster check failed. elasticsearch #678 had the same problem and worked around it with long retries.

• Local run, redis-cluster 1.7.0 fresh install in test-gvc-3: all checks pass and teardown is clean. A side-by-side poll showed the 6 replicas becoming ready one at a time over about 4 minutes, with desiredScale: 6 reported from the start.

This PR changes only .github/ and the guide, so its own e2e run tests nothing. The proof is a manual run of redis-cluster and elasticsearch from this branch, linked below.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FZrfgWEQM4Kb8nMRmMPHEC

[jacobecox]

Proof run from this branch: https://github.com/controlplane-com/templates/actions/runs/40593636101. redis-cluster 1.7.0 (fresh install, and upgrade from 1.4.3) and elasticsearch 1.0.1 (fresh install, and upgrade from 1.0.0) pass every check. On the elasticsearch fresh install, cluster-green passed 5 s after the install was reported ready. Before this change it needed about 4 minutes of retries. This PR's own run selected nothing to test, which is correct.