push blocks root when clean member is only behind remote

[mostlydev]

Summary

gnit push can hold back the workspace root when an unrelated clean member is behind its remote, even when that member has no local commits to publish for the current change.

This showed up during a DP2 root-only push. The root repo had the actual new commit, the other members were clean, but flux-docs had advanced remotely. gnit push tried to push flux-docs, hit a non-fast-forward rejection, and held the root back.

Observed

Initial workspace state:

Workspace dicom-printer-2   root: /Users/wojtek/dev/cpp/dicom-printer-2
Current pin: console-log-split-pane

Repos
  root        clean   on master
  dicom-printer-2-control  clean   on master
  dicom-printer-2-drop-monitor  clean   on master
  flux-docs   clean   on master  drifted from pin

git status in the root repo showed master...origin/master [ahead 3].

Running gnit push failed:

Error: push incomplete; resolve failures and run `gnit push --resume`
Push report:
  member dicom-printer-2-control already landed
  member dicom-printer-2-drop-monitor already landed
  member flux-docs   failed: rejected (non-fast-forward)
  workspace root     held back: members incomplete; root not published

flux-docs looked locally clean/aligned before refreshing:

## master...origin/master
HEAD == origin/master == d930159a834ac0752cd696c1e7aeaea71eb23b42

But a direct push reported fetch-first:

! refs/heads/master:refs/heads/master [rejected] (fetch first)

After fetching flux-docs, it was only behind remote:

From https://github.com/fluxinc/flux-docs
   d930159..833e329  master     -> origin/master
## master...origin/master [behind 5]

Fast-forwarding that clean member and resuming unblocked the push:

git -C flux-docs merge --ff-only origin/master
gnit push --resume

Push report:
  member dicom-printer-2-control already landed
  member dicom-printer-2-drop-monitor already landed
  member flux-docs   already landed
  workspace root     pushed
push complete

Expected

For a member with no local commits to publish for the current push/change, remote advancement should not block publishing the workspace root. Reasonable behaviors would be one of:

• pre-fetch members before deciding whether there is anything to push;
• treat a clean member that is only behind origin/<branch> as already landed for this push;
• automatically fast-forward a clean behind member before retrying the member push; or
• report a targeted remediation that says the member is behind remote and needs git -C <member> merge --ff-only origin/<branch>.

Actual

gnit push and gnit push --resume repeatedly attempted/treated the stale clean member as a failed member push, then held back the workspace root.

Impact

This makes an unrelated member's remote activity block publishing a root-only change. The manual workaround is safe but operationally surprising, especially because the member initially displays as clean/aligned until explicitly fetched.

Environment

• gnit 0.9.1
• workspace: dicom-printer-2
• branch: master
• failing member: flux-docs