fix(sandbox): refresh install fingerprint after boot fast-forward

[pedrofrxncx]

Bug found while reading packages/sandbox/daemon/setup/orchestrator.ts after the recent auto-fast-forward feature (#5390) and the no-install reporting fix (#5398).

Bug: stepClone() calls gitSetup(config) (which checks out the branch and calls refreshBranchHead() to snapshot currentBranchHead) and only afterward calls maybeFastForwardToBase(config.repoDir). stepInstall()'s install-skip cache (installState.isInstalledFor(config, this.currentBranchHead)) and its markInstallSucceeded call both key off that same currentBranchHead field. Since the field is captured before the fast-forward runs, it's fingerprinting against the pre-fast-forward commit even though the fast-forward may have just advanced the branch (and its lockfile) further.

Failure scenario: an idle sandbox on branch feat/x (no local commits) resumes on boot. feat/x is behind origin/main. The fast-forward advances feat/x to origin/main before install runs, and install correctly picks up the new lockfile from disk — but the success is recorded under the stale, pre-fast-forward commit SHA. On a later boot/resume cycle where feat/x lands back at that same pre-ff commit (e.g. base hasn't moved further yet), the install-skip cache matches that stale fingerprint and skips the install entirely, even though a fresh fast-forward in that same cycle may have just changed the lockfile again.

Fix: move the refreshBranchHead() call to run after maybeFastForwardToBase() in stepClone, so the fingerprint reflects the actual commit that was installed against (removed the now-redundant call inside gitSetup, its only caller).

Regression test: added SetupOrchestrator install fingerprint after boot fast-forward in orchestrator.test.ts — sets up a real local bare repo with main two commits ahead of feat/x, clones feat/x, drives the orchestrator through a branch-change transition, and asserts the branch-head value passed into installState.isInstalledFor equals the actual post-fast-forward git rev-parse HEAD. Verified the test fails (captures the pre-fast-forward SHA) on the pre-fix code and passes after the fix.

To verify: cd packages/sandbox/daemon && bun test setup/orchestrator.test.ts -t "post-fast-forward"

Checks run locally: bun run fmt, bunx tsc --noEmit in packages/sandbox (clean), and the single targeted test file above (14/15 pass; the one pre-existing failure — "reinstalls the pre-push hook after an install script clobbers it" — fails identically on main due to a missing corepack binary in this local sandbox, unrelated to this change). Full CI runs the rest of the suite.

---

Summary by cubic

Fixes a stale install fingerprint after boot-time fast-forward by re-reading HEAD after the fast-forward. This ensures the install cache keys off the post-FF commit and avoids skipping needed installs when the lockfile changes.

• Bug Fixes
  • In stepClone(), run maybeFastForwardToBase() before refreshBranchHead(), and remove the redundant refresh in gitSetup(), so the fingerprint uses the post-fast-forward SHA.
  • Added a regression test that verifies installState.isInstalledFor receives the post-FF HEAD.

^{Written for commit e2dd153. Summary will update on new commits.}