ci: fix monthly-refresh re-trigger self-stall on 6h timeout

[gabrielspadon]

Problem

Cold-cache validation of the Monthly Pipeline Refresh (run #68) revealed the workflow cannot auto-continue after the 6h job timeout, so it never reaches convergence unattended.

Evidence from #68 (28631390920):

• Pipeline code is healthy cold: run 1 (cold) 8479 API calls / 5212 cached, run 2 6816 API calls / 5322 cached — count trending down (converging), zero pipeline errors.
• Only ~3 iterations fit in the 6h timeout-minutes; convergence needs more. On timeout, refresh is cancelled and verify (if: always()) should re-trigger a successor — but its log shows ##[notice]Another run is already in progress — skipping re-trigger.

Root cause

The guard counts in-progress runs but includes the current run. While the verify job runs, its own run is still in_progress, so a timed-out run always sees count >= 1 and self-skips the re-trigger. (A manual cancel flips the run to cancelled before verify checks, which is why #67 -> #68 re-triggered fine; a timeout does not.) This stalls the monthly chain — also explains the 07-01 scheduled runs that died with no successor.

Fix

Exclude ${{ github.run_id }} from the in-progress count, so the guard only fires for a genuinely different concurrent run. Cascade-prevention intent preserved.

One-line change to the verify job's re-trigger guard.

[Copilot]

Pull request overview

Fixes a self-stalling condition in the Monthly Pipeline Refresh workflow where the verify job incorrectly counts the current workflow run as “another run in progress,” causing timed-out runs to skip the intended re-trigger and preventing the refresh chain from converging unattended.

Changes:

• Adjust the re-trigger guard to exclude the current github.run_id from the in-progress run count.
• Add clarifying comments explaining why excluding the current run is necessary (timeout vs manual cancel behavior).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.