[bug] push: bare --force-with-lease ignored on remote groups

What did you do before the bug happened? (Steps to reproduce your issue)

Pushed a non-fast-forward update to a remote group using the bare --force-with-lease option (no <refname>[:<expect>] argument).

Minimal reproduction with two file-based remotes grouped as "both":

    git init --bare RemoteA.git
    git init --bare RemoteB.git
    git init -b main work && cd work
    git remote add RemoteA ../RemoteA.git
    git remote add RemoteB ../RemoteB.git
    git config remotes.both "RemoteA RemoteB"
    echo 1 >f && git add f && git commit -m one
    echo 2 >>f && git commit -am two
    git push RemoteA main && git push RemoteB main
    git fetch --all
    git reset --hard HEAD~1
    echo 3 >>f && git commit -am three

    GIT_TRACE=1 git push --force-with-lease --dry-run both main

What did you expect to happen? (Expected behavior)

The --force-with-lease non fast forward push to happen to both remotes.
     + d30bde7...c21af72 main -> main (forced update)

The same as would happen if the pushes were done individually

What happened instead? (Actual behavior)

Both pushes are rejected as non-fast-forward and the command exits 1:

     ! [rejected]        main -> main (non-fast-forward)

What's different between what you expected and what actually happened?

Both pushes failed, seemingly not receiving the --force-with-lease flag

Anything else you want to add:

GIT_TRACE showed that a bare --force-with-lease does not forward the flag to the child processes that are spawned to execute the push on each remote.

12:10:42.376196 git.c:506 trace: built-in: git push --force-with-lease --dry-run both main 12:10:42.376772 run-command.c:673 trace: run_command: git push --dry-run RemoteA main Pushing to RemoteA 12:10:42.377701 run-command.c:765 trace: start_command: /root/git-builds/next/libexec/git-core/git push --dry-run RemoteA main 12:10:42.380551 git.c:506 trace: built-in: git push --dry-run RemoteA main

The issue does not happen when an explicit <refname> is specified

12:10:42.420633 git.c:506 trace: built-in: git push --force-with-lease=main --dry-run both main 12:10:42.421239 run-command.c:673 trace: run_command: git push --dry-run --force-with-lease=main RemoteA main Pushing to RemoteA 12:10:42.421423 run-command.c:765 trace: start_command: /root/git-builds/next/libexec/git-core/git push --dry-run --force-with-lease=main RemoteA main

The issue also does not impact the normal --force flag

12:10:42.437825 git.c:506 trace: built-in: git push --force --dry-run both main 12:10:42.438310 run-command.c:673 trace: run_command: git push --force --dry-run RemoteA main Pushing to RemoteA 12:10:42.438508 run-command.c:765 trace: start_command: /root/git-builds/next/libexec/git-core/git push --force --dry-run RemoteA main 12:10:42.439223 git.c:506 trace: built-in: git push --force --dry-run RemoteA main

Reproduced on:
  - git 2.56.0.windows.4 (Git for Windows, where I first spotted the bug)
  - git 2.56.0 (built from source on Linux/WSL2)
  - git 2.56.0.341.gebdc087dc9 (master, built from source on Linux/WSL2)
  - git 2.56.0.506.g506a7eabc5 (next, built from source on Linux/WSL2)

--dry-run is used above only to make the reproduction repeatable; the same rejection happens without it.

[System Info]
git version:
git version 2.56.0.506.g506a7eabc5
cpu: x86_64
built from commit: 506a7eabc523d0811286b66193419658da95cda5
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
rust: enabled
feature: fsmonitor--daemon
libcurl: 8.18.0
OpenSSL: OpenSSL 3.5.5 27 Jan 2026
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-storage-format: files
default-hash: sha1
uname: Linux 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC
Thu Jun  5 18:30:46 UTC 2025 x86_64
compiler info: gnuc: 15.2
libc info: glibc: 2.43
$SHELL (typically, interactive shell): /bin/bash

[Enabled Hooks]