COmmit the staged changes. This enables showing the actual info coming from the server:

Branch protection violation
! \[remote rejected\] branch-test -> branch-test (upstream: push declined due to repository rule violations)
error: failed to push some refs to 'X'

Invalid ref:
! \[remote rejected\] test-prefix -> test-prefix (ref name conflicts with an existing ref namespace)
error: failed to push some refs to 'X'

Now for perms:
! \[remote rejected\] new-test/repo -> new-test/repo (pushing to GitHub: tracing transport: handshake: http transport: authorization failed: unexpected requesting "https://github.com/x/x/info/refs?service=git-receive-pack" status code: 403: Permission to x/x.git denied to <user>.)
error: failed to push some refs to 'X'

Add those examples on the commit message.

**Files to stage:**
- `internal/remotehelper/githelper/push.go`

**Draft message:**

```\ngit-remote-entire: relay helper-status before send-pack exit check

send-pack exits non-zero on per-ref rejections (D/F conflict, protected\nbranch, server hook decline). The buffered `error refs/X <reason>` lines\nare what git's transport-helper.c reads to render the user-visible\n`! \[remote rejected\]` output. Forwarding helper-status only on the happy\npath meant Wait/feed errors swallowed those lines, leaving users with\nonly `send-pack exited with error: exit status 1`.

Relay helper-status before checking exit codes so the real reason\nreaches the user. Examples now surfaced:

Invalid ref:
   ! \[remote rejected\]     test-prefix -> test-prefix (ref name conflicts with an existing ref namespace)
  error: failed to push some refs to 'X'

Permissions:
   ! \[remote rejected\]   new-test/repo -> new-test/repo (pushing to GitHub: tracing transport: handshake: http transport: authorization failed: unexpected requesting "https://github.com/x/x/info/refs?service=git-receive-pack" status code: 403: Permission to x/x.git denied to <user>.)
  error: failed to push some refs to 'X'

Assisted-by: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Paulo Gomes <paulo@entire.io>
```

This control-flow change is important user-facing behavior, but there’s no regression test covering handlePush output when send-pack exits non-zero (per-ref rejection). Given the amount of existing protocol-level test coverage in this package, please add a unit test that simulates a failing git send-pack --helper-status and asserts that the helper-status lines are still written to stdout before handlePush returns an error (e.g., by placing a stub git executable early in PATH that emits the expected pktline + helper-status and exits 1).

**File:**`internal/remotehelper/githelper/invariants_test.go`

**Draft message:**

````git-remote-entire: regression test for helper-status on send-pack error

handlePush relays send-pack's helper-status lines to stdout before\nchecking the subprocess exit code, so per-ref rejections (branch\nprotection, D/F conflict, server hook decline) reach git's\ntransport-helper.c and render as `! \[remote rejected\] <ref> (<reason>)`.
Pin that ordering: a PATH-injected shell stub plays the role of\n`git send-pack`, emits an empty wrapped request followed by a trailing\nflush + `error <ref> ...` helper-status line, and exits 1. The test\nasserts that handlePush both returns the exit error AND has already\nwritten the helper-status to stdout. Verified failing against the\npre-fix push.go (helperStatus empty in stdout).

Assisted-by: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Paulo Gomes <paulo@entire.io>
````