fix(back-merge): do not wait for green on a downstream carry

[rubenvdlinde]

A back-merge moves content downstream — main → beta → development — and everything it carries has already passed the quality workflow further up the chain. A Dependabot bump that reached main was gated on main. Re-running the same checks on the same commits on the way back down adds no information.

What the gate actually cost

These pull requests sit on branches that are red for reasons of their own: a stale beta failing today's gates, a release job with no signing credentials. None of that has anything to do with the commits being carried — and waiting for green there means the ancestry is never repaired, so every following promotion conflicts on the same version file, forever. That is the failure this workflow exists to end.

Measured on the first real run:

TOTALS: carried=20  in-sync=6  skipped=16

with most skips being "carries content, left for review" on branches whose red had nothing to do with the carry.

Where a real break still surfaces

The up-merge. development runs the full suite on every push, and development → beta runs it again with E2E. A defect carried down is caught one hop later, against a smaller diff.

What is deliberately unchanged

• A CONFLICTING pull request still cannot merge.
• Anything conflicting outside the version files is still refused rather than resolved automatically — that guard is what stopped .forgejo/* Codeberg leftovers being resurrected on seven apps in the first run.
• --merge, never --squash, so the carry does not reopen the gap it just closed.

The header prose is updated along with the predicate, rather than left describing the old rule.

Verified: YAML parses; bash -n on each run block extracted from the parsed YAML; no dangling references to the removed pr_is_green helper.