Work around potential issues in CI/CD workflows caused by changing target branches

Problem:

1. A stack is pushed: main <- A <- B <- C
2. Part of the stack is merged: main (A) <- B <- C. B's base ref is updated from A to main
3. For some reason part of the verify workflow for B is retriggered. It may be because it had not yet ran (rare) or had a transient failure and needs to be re-ran without any code changes made.
4. Some workflow actions such as https://github.com/13rac1/block-fixup-merge-action attempt to determine the base ref from the env var GITHUB_BASE_REF, but this is wrong because it's still pointing to the jaspr branch for A which has been deleted. Why this value is "cached" I'm not clear on.

While this doesn't seem like a jaspr bug specifically, I can see several GH actions not responding well to a PR's base branch being changed while the PR's branch doesn't move. To work around this, consider when retargeting B to rewrite the stack (no code changes, just a bump to the commit date) and do a new push.

No files or tests are named. Start at the retargeting flow for stacked pull requests and reproduce the main <- A <- B <- C sequence, including a retriggered verification workflow after B changes base. Done means retargeting B causes a fresh push or equivalent update so GitHub Actions use the current base ref.