ci: guard ratchets compare to main's tip at section start, not the run's build base #4861

The guard-tree and guard-cargo sections fetch the origin/main tip when the section starts, and every baseline ratchet in them compares against it. A section can start hours after the merge commit it judges was built, so a branch that never touched a baseline goes red when main shrinks that baseline in the meantime.

Observed (#4813): the run built merge 092b5e990 on base 358e9d4d11, where scripts/pipe_grep_q_baseline.txt records 62. The guard section started later, when main was ece9e563bd; da7059c5c7 had shrunk the count to 60 in between. check_baseline_ratchets reported pipe_grep_q_baseline.txt GREW (62 vs 60). #4813 does not touch the file.

Fix: pin refs/remotes/origin/main to the run's build base before the guard steps: the first parent of the merge commit on pull_request, merge_group.base_sha on merge_group (as the refinement gate already does), and the tip (deepened by one on push) otherwise. Re-adding an entry main deleted is still refused, by the merge_group run, which is built on main as it merges.

Epic: #3863