Fill the run workspace from the base commit, not by merging into it

[artyomsv]

A /fix on a pull request that EDITS an existing file never started: the init container exited 1 before the agent ran.

{"event":"failed","cause":"CLONE_FAILED",
 "detail":"CheckoutConflictException: Checkout conflict with files:
           src/main/java/com/billing/Billing.java"}

Why

WorkspaceClone.populate clones with setNoCheckout(true) — no working tree, empty index, HEAD still on the remote's default branch — and then runs checkout -b branch startPoint.

That checkout is a two-way merge from the default branch's tree to the target's. A path present in both with different content reads as a local edit JGit must not silently overwrite, so it refuses the whole checkout. The index being empty is what makes the phantom edit.

Nothing meets this while the target commit is on the default branch, because then the two trees agree. A fix run is the case that is not: ADR-040 starts it at the pull request's own head, so the first file that pull request edits conflicts.

setForced(true) was tried and does not fix it — in JGit that forces the ref update, not the working-tree overwrite.

The fix

Point HEAD at the new branch first, then fill the empty workspace from it with a hard reset. That is a one-way checkout: it writes the index and work tree from the target with no prior state to conflict against, which is exactly the situation — the workspace is empty by construction.

Why no test caught it

Every existing case seeds a default branch whose later commit only adds a file, so no path is ever in both trees with different content. The same held by luck in production: the only fix branch that had ever run, demo/discount, added one file and edited none. Four fix runs passed on it.

The new test builds the shape that was missing — a branch that edits one file and adds another — and asserts the resulting content, not merely the absence of a throw. Forcing the checkout without populating the work tree would pass a throw-only assertion and leave the run unit with an empty workspace.

Verification

• :spire-workspace:test 57 tests, :spire-publisher:test 58, :spire-run-worker:test 260 — 0 failures. M0WalkingSkeletonTest (real Docker, real git origin) green.
• ./gradlew testFast testServices BUILD SUCCESSFUL.
• Mutation: restoring the old checkout -b fails aPullRequestBranchThatEditsAFileCheckoutsOutCleanly and nothing else — 6 tests, 1 failed.
• Reproduced first as a red test against the unfixed code, with the same exception and the same "edited file conflicts, added file does not" split seen in production.

Impact

Every /fix on a pull request that edits an existing file — most pull requests. The M2 loop worked only because the one branch it had ever run on added a file and edited none.

Still open, not in this change

The row records init container failed with exit 1. The real cause — CLONE_FAILED, the exception, the filename — reached only the container's stdout as structured JSON, and nothing salvages it into failure_detail. Diagnosing this needed docker logs, which is the gap the runs detail screen exists to close.