Regenerate translations and PSR2 on the PR; leave the merge sync the version

[darksidemilk]

Part 1 of 2. Formatting and the translation catalogue are corrected on the pull request, before review, instead of by a bot commit landing on working-1.6 afterwards. Part 2 (claude/psr-lang-pr-tests-2a3kv7-version-sync) moves the version too.

⚠️ This PR shows no checks at all until FOGProject/fog-workflows#29 merges

Not "the new job is red" — the whole workflow fails at startup, so the test suite doesn't run either. GitHub reads tests.yml, can't resolve fogproject-pr-regen.yml@main because that file only exists on the fog-workflows PR branch, and reports a workflow file issue: no jobs, no logs, zero check runs. Observed on run 32805320370, which failed in the same second it was created.

This is inherent to a cross-repo stacked change, and it resolves the moment #29 lands — that PR is behaviour-neutral on its own (new file with no caller; version_only defaults false), which is why it's ordered first. Re-run this workflow afterwards and the suite will run normally.

If you'd rather validate this PR before merging anything, the alternative is to point the uses: line at @claude/psr-lang-pr-tests-2a3kv7 temporarily and flip it back to @main before merge — testable immediately, at the cost of a line that must not be forgotten.

working-1.6 only for now — dev-branch follows once this is proven here, and it is a one-line change to the base-ref guard. master and stable are untouched.

What changes

.github/workflows/tests.yml gains a regen job calling fog-workflows' fogproject-pr-regen.yml. needs: suite is the whole gate: a caller job that uses: a reusable workflow succeeds only if every job inside it did, so that already means "all current tests passed".

The logic stays in fog-workflows; what lives here is the policy of which PRs are eligible — branch-local information, and exactly where sync-generated-files.yml already keeps the identical allowlist.

.github/workflows/sync-generated-files.yml passes version_only: true. By the time a same-repo PR merges its formatting and catalogue are already right, so redoing them costs a fog-plugins download and a full gettext regeneration for a guaranteed no-op.

The version can't move to PR time this way — it's the commit count since master, and the merge commit itself changes that count — so correcting it stays a post-merge job here. Part 2 handles it.

Two guards worth reviewing closely

Same-repo. pull_request withholds secrets from a fork, so there's no App token to mint; the App isn't installed on the contributor's account anyway; and pushing to a fork head needs maintainer_can_modify, which is theirs to set. Fork PRs keep being picked up by the daily sweep after merge, exactly as today. Same guard, same reason, as the one already in sync-generated-files.yml.

Head denylist — not decoration. Workflows for a pull_request are read from the merge of head into base, so a PR whose head is a long-lived branch runs this file too. stable-releases.yml opens exactly one of those (stable → dev-branch) to sync a release back. It's unreachable while the base allowlist names only working-1.6; it's there so that stays true when the allowlist grows, rather than being discovered by pushing commits onto stable.

The loop question

The regen job pushes, and that push raises synchronize, so this file runs again. Bounded, not open-ended: both operations are idempotent, so the second run finds nothing and pushes nothing — one extra run and one bot commit per contributor push. The full argument, plus the runtime assertion and the hard bot-commit bound that hold even if that argument stops being true, are in the fog-workflows PR and in that workflow's header. The header here is updated too, since the old text said this file only reads.

What to expect after merging

A PR that needed no corrections sees regen run and do nothing. A PR that did gets one bot commit and one extra suite run. The merge-time sync then reports only a version change, or no change at all.