Other workflows still diff against the stale event-payload base SHA (FC-stale-event-payload-diff-base)

[Git-on-my-level]

While fixing #10784 (which registered FC-stale-event-payload-diff-base after PR #10758 hit a false invariant-citation failure), I found the same pattern — using github.event.pull_request.base.sha as a diff base instead of resolving origin/<base_ref> live against the checkout — in four other workflows:

• .github/workflows/backend-unit-tests.yml:138
• .github/workflows/desktop-swift-ci.yml:38
• .github/workflows/backend-hermetic-e2e.yml:35 (PR_BASE_SHA)
• .github/workflows/desktop-backend-image-checks.yml:35 (BASE_SHA)

These jobs trigger on code-changing events (synchronize/opened), where the payload field is populated by the same event that needs it, so the staleness window is much narrower than repo-checks.yml's metadata-preflight job (which trigges on metadata-only edited/labeled/unlabeled events with no new commit, and was the actual cause of the #10758 failure). It's not zero-risk though: a delayed/queued run, or a job that reads a payload field captured well before it actually executes, can still diff against a base the target branch has since moved past — silently widening or narrowing the diff-scoped check selection.

Not fixed in #10784 to keep that PR narrowly scoped to the failure actually observed and verified. Worth auditing each of these four call sites against FC-stale-event-payload-diff-base's canonical_prevention and switching to a live-resolved base where it's cheap to do (matching the detect-changes action's existing pattern), or documenting why the payload field is intentionally correct there if it is.