fix(git-init): push workspace to GitHub when remote already has main (#256)

[dolho]

Summary

Fixes #256. initialize_github_sync silently succeeded without actually pushing the agent's workspace to GitHub whenever the target repo already had a main branch (e.g., a README).

Root cause

initialize_git_in_container in services/git_service.py had two code paths depending on whether origin/main existed:

• Empty remote (no main): ended with git push -u origin main --force ✓
• Remote has main: did git reset origin/main → git add . → git commit — and then nothing. No push.

The commit lived inside the container forever. The DB row was written, the UI reported success, but GitHub never saw the workspace. This triggered in two very common scenarios:

1. Pre-created a GitHub repo with a README, then tried to initialize Trinity sync against it
2. Pointed at any existing repo that already had history

Fix

Added git push -u origin main to the remote_has_main command list — fast-forward push (not --force), since we're one commit ahead of origin/main and want to preserve any history already on the remote. Push runs even on the "nothing to commit" path so upstream tracking still gets set.

     if remote_has_main:
-        # Preserve remote history: reset to origin/main, then commit local changes
+        # Preserve remote history: reset index to origin/main, then stage
+        # the current workspace on top of it and fast-forward push.
         commit_commands = [
             'git reset origin/main',
             'git add .',
             'git commit -m "Initial commit from Trinity Agent" || echo "Nothing to commit"',
+            # Always set upstream; no-op when there is nothing new to push.
+            'git push -u origin main',
         ]

Test plan

Unit tests (tests/unit/test_github_init_push.py, 4 new tests)

• test_empty_remote_force_pushes — regression pin for the previously-working empty-repo path
• test_existing_remote_pushes_after_commit — the fix: push now happens in the remote_has_main branch
• test_existing_remote_reset_precedes_commit — command order: reset → add → commit → push
• test_existing_remote_nothing_to_commit_still_pushes — push runs even when commit was a no-op

Verified that 3 of 4 tests fail against the pre-fix code and all 4 pass with the fix.

Manual end-to-end (verified firsthand against real GitHub)

• Case A — the bug path: pre-created YOUR_USER/trinity-256-test --add-readme, created a fresh blank Trinity agent, ran Initialize GitHub Sync against it. Confirmed the agent's workspace commit now appears on GitHub on top of the README commit. (Before the fix: the UI reported success but only the README existed remotely.)
• Case B — regression check: pre-created an empty repo (no --add-readme), ran init, confirmed the empty-remote force-push path still produces a single Initial commit from Trinity Agent on main with the workspace contents.

Notes / follow-ups (out of scope for this PR)

• https://oauth2:{PAT}@github.com/... embeds the PAT in the remote URL. On git errors, git often writes the remote URL to stderr, which then flows into the HTTPException detail and server logs. Blast radius is low (gated on OwnedAgentByName, so the leak is to the PAT owner themselves) but worth fixing separately via git credential.helper / GIT_ASKPASS.
• "Nothing to commit" string-matching to detect no-op commits is fragile but pre-existing.

🤖 Generated with Claude Code