levain 0.6.2

0.6.1 was tagged and never published: CI on its tagged commit failed on Linux (a project's own commit hook ran during the replay), so what follows is 0.6.1's content plus the fix for that. No schema, id or exit-code change; the anneal floor stays at 0.9.36.

Hardening of the team layer's sync replay, from the known-open list of 0.6.0. No schema, id or exit-code change; the anneal floor stays at 0.9.36.

Fixed

• Team sync replay (the 0.6.0 known-open list). When levain team sync has to replay local entries after a team.toml/PROJECT.md conflict:
  • git's rerere is switched off for the replay (rerere.enabled=false, rerere.autoupdate=false), so a recorded resolution can no longer turn a local entry into an apparently empty pick that was then skipped as "already upstream".
  • A pick is skipped as "already upstream" only when git itself stopped on it (exit 1, CHERRY_PICK_HEAD naming that very commit, nothing unmerged, nothing staged). A cherry-pick that fails for another reason (a stale index.lock, another pick already in progress) now stops the sync with git's own message and leaves the branch where it was, instead of failing in cherry-pick --skip with the wrong cause or dropping an entry.
  • Every git command levain runs on the ledger runs with the project's own git hooks disabled (core.hooksPath=/dev/null, set once in the one place git is called). Git on Linux runs a repository's commit, checkout and reference-transaction hooks on exactly these operations: a failing prepare-commit-msg made levain team sync fail on a conflict replay, and a hook that rewrites the index could make a real entry look like an empty pick. Found by CI on the 0.6.1 tag, not by review, and the first fix (the flag on two commands) was found incomplete by all three review lineages. The replay's rebase also no longer tries to GPG-sign (cherry-pick and levain's own commits already did not).
  • Local commits are replayed in topological order (--topo-order), so skewed commit clocks cannot reorder them.
  • If the replay was published but the worktree could not be moved back onto the branch, the discard warning is still printed (it used to be lost with the error), the checkout is retried forced, and only if that fails too does the error name the git checkout -f to run.
  • A failure while re-attaching the worktree after a failed replay no longer replaces the error that caused the replay to fail; it is reported as a warning that the worktree was left detached and that the next command re-attaches it.
    The rerere skip itself (a copied .git plus rerere autoupdate) was reasoned from review and not reproduced; the flags are pinned by a test that reads the git command lines. The wrong-cause, stale-marker, re-attach and post-publish cases are pinned by tests that inject the failing git result and fail on 0.6.0; the "already upstream" skip is pinned by a real git run. Known limits: if both the checkout and the forced re-attach fail, the error names the first failure only; a conflict in the replay is reported as "git could not run: <git's last line>".