Forward-merge automation doesn't build/test before pushing to target branch

[phaedrus1992]

Found while cleaning up after sprint #524/PR #526. The forward-merge automation
(.github/workflows/forward-merge-release.yml) merges release/X.x into main and pushes the
result directly — but it never builds or tests the merge result before pushing. A merge with no
textual conflict is treated as fully successful even when the two branches independently changed
the same function's signature (or any other change that's line-disjoint but semantically
incompatible).

What happened: PR #526 (this repo, release/1.x) added a test calling
sync_admin_credentials(&client, &app, transmission_access) — matching that function's
3-parameter signature on release/1.x at the time. Independently, main already had a
4-parameter version of the same function (a base_url_override parameter from an unrelated,
already-merged feature that was never backported to release/1.x). When PR #526 merged and the
forward-merge cascade ran, git merge combined both changes with no conflict (they touched
different lines), but the result didn't compile: the test call site was now missing the new
4th argument, main was left unbuildable, and the "Forward-merge release branches" workflow run
reported success.

Impact: main was uncompilable for ~12 minutes until manually caught locally and fixed via
PR #527. Nothing in CI caught it — main's own CI workflow never triggered a fresh run against
the forward-merge commit (the push may not match its trigger conditions, or it's debounced/
skipped somehow — worth checking .github/workflows/ci.yml's on.push config too).

Fix pattern: add a build/test step to the forward-merge cascade before pushing to each
target — e.g. cargo build --workspace --tests (or the project's actual CI test command) run
against the merged worktree, right after the git merge --no-edit step and before
push_branch. If the build fails, treat it the same as a conflict: abort the merge, halt the
cascade, and surface actionable instructions (this repo's build failure, not a git conflict, so
the message should say so explicitly and suggest git merge locally + fixing the build before
pushing). Separately, worth confirming why main's CI didn't run post-merge as a backstop --
if it's supposed to and didn't, that's a second gap.

[phaedrus1992]

Hit this exact failure mode concretely today: the auto-forward-merge of release/1.x -> main (after PRs #566/#570 merged) conflicted on CLAUDE.md and halted, so I did it manually. After resolving the conflict, origin/main itself (before my merge even touched it) failed to build — confirmed by checking out origin/main standalone in a scratch worktree and running cargo build --all-targets. Two missing struct fields (Context::app_api_base_override/legacy_image_override_apps, PersistenceSpec::removed_default_volumes) from an earlier forward-merge, plus a duplicate watch_all_namespaces fn from this one. This is the second time (a4d1ebd fixed an earlier instance) — the automation pushing straight to main without a build/test gate lets broken merges land and then keeps building on top of broken main until someone notices by hand.