fix(qa): make the QA Session publish path safe on a shared branch

[FenrysUnchained]

Follow-up to #799. Two fixes to the QA Session window's publish step, both on the path a tester takes from bleeding-edge — which is the default path now that #799 has merged, and which had never actually run: all testing before this was on a working branch, which takes a different branch of the code.

Found while re-reading that path before walking a first-time user through the tool.

1. -u on a refspec push hijacked the tester's upstream

The protected-branch path pushes to qa/results-<session> rather than checking anything out. That push carried -u.

With a refspec, -u sets the upstream of the source ref — the tester's current branch — not the ref being created. Reproduced in a scratch repo:

$ git push -u origin HEAD:refs/heads/qa/results-demo
branch 'bleeding-edge' set up to track 'origin/qa/results-demo'

So a tester who pressed Submit on bleeding-edge had their local bleeding-edge silently re-pointed at a QA results branch, and their next Pull origin in GitHub Desktop would have pulled that branch into the build they were testing. The tool reported success while doing it.

Dropping -u fixes it and still publishes the ref (verified in the same scratch repo: branch created, upstream left on origin/bleeding-edge). Nothing local tracks the QA ref and the tester never checks it out, so it needs no upstream.

2. Publishing no longer moves anything the tester owns

The same path still made a local commit before pushing it, which left bleeding-edge one commit ahead of origin forever — with a Push button in GitHub Desktop that either errors or, if the branch isn't protected server-side, lands a QA results commit directly on bleeding-edge.

No local commit is made at all now. The commit object is assembled with plumbing and pushed directly:

read-tree HEAD  →  add PATHS  →  write-tree  →  commit-tree  →  push

against a throwaway index (GIT_INDEX_FILE), which is also what keeps it scoped — whatever else the tester has dirty or staged is invisible to it. HEAD, the branch, the real index and the working tree are all untouched.

refs/qa-published/<stem> records what was last published for a session and parents the next publish, so a second submit fast-forwards the QA branch instead of being rejected as unrelated histories. It also keeps that commit object reachable against gc, and sits outside refs/heads so it never appears as a branch.

Shared infra

FrogletGit gains RunInWithEnv / RunWithEnv. Environment variables are the only way to reach GIT_INDEX_FILE — it has no command-line equivalent — and staging into a throwaway index is what lets any tool build a scoped commit without disturbing the human's index, branch or working tree.

Pure refactor: RunIn now delegates with a null env, so every existing caller (BugLedgerPublisher ×4) is byte-identical in behaviour.

---

Verification status

Prototyped against real git before any C# was written, checking the things that actually bite:

HEAD unmoved	✅ local == origin after publishing
upstream intact	✅ still origin/bleeding-edge
branch not ahead	✅ ## bleeding-edge...origin/bleeding-edge
scoped	✅ an unrelated dirty file was not in the pushed tree
repeat submit	✅ second publish fast-forwards the QA branch

Compiled for real (Roslyn, exit 0) — both QASessionWindow.cs and, because this touches shared infra, FrogletGit.cs itself against the real System.Diagnostics.Process ref assembly, so the process plumbing is type-checked rather than stubbed.

65 Python self-test checks green (30 session / 18 submit / 17 apply); check_conditional_compilation.py clean.

NOT verified — needs a human at a Unity install: the end-to-end press of Submit from bleeding-edge. The git sequence is proven, and the C# that drives it compiles, but no one has run the two together through the editor. That walkthrough is imminent and this PR is the version it should be run against.

If it does misbehave, the failure is loud and safe: the dialog falls back to naming the two files to commit by hand, and the results are already saved in the session file regardless.

🤖 Generated with Claude Code

---

Generated by Claude Code