fix(checkpoint): surface git-refs push queue failures

[ChetanReddyC]

Summary

• return an explicit partial failure when a git-refs checkpoint is written locally but cannot be added to the push queue
• preserve the local ref and retryable condensation state, then re-enqueue on a later write
• add store-level and condensation-level regressions and update the architecture contract

Closes #2393

Why this approach

The ref update and queue append cannot be one atomic operation. Rolling back a valid local ref would discard recoverable data, while scanning every local checkpoint ref during pre-push would conflict with the queue's purpose and with fetched-ref semantics. This change therefore makes the partial outcome explicit at the store boundary. The existing fail-soft post-commit caller then preserves session and shadow state so the same checkpoint can be retried safely.

I believe this is the smallest complete fix that fits the current architecture. I would appreciate the maintainers' direction on this approach, and I am happy to adjust it or continue the work under your guidance.

Verification

• go test ./cmd/entire/cli/checkpoint ./cmd/entire/cli/strategy -run '^(TestGitRefsStore_WriteReportsQueueFailureAfterRefUpdate|TestCondenseAndUpdateState_QueueFailurePreservesRetryState)$' -count=1
• go test ./cmd/entire/cli/checkpoint ./cmd/entire/cli/strategy -run '^$' -count=1
• golangci-lint run ./cmd/entire/cli/checkpoint/... ./cmd/entire/cli/strategy/... (0 issues)
• git diff --check upstream/main..HEAD

Broader package test runs on this Windows host encounter existing temporary-repository cleanup failures where .git remains locked; the focused regressions and package compilation above pass.

Session metadata

Codex checkpoint capture was not active for this local Windows linked-worktree session, so no genuine checkpoint trailer was available.

[MuskanPaliwal]

Hey @ChetanReddyC, I noticed your note about unresolved Codex hook discovery. I addressed worktree and .bare hook discovery in #2052, including warnings that show which hooks file Codex reads and what needs fixing.

Which Entire version are you running, and could you share the Codex section of entire doctor? Did Entire show a warning when you enabled Codex or started a session? I’d like to understand what’s still failing in your setup.

[ChetanReddyC]

Hey @MuskanPaliwal Thanks for checking. To clarify, this was specific to my local Windows linked-worktree session, where Codex checkpoint capture was not active. Inside the Codex sandbox, entire doctor also encountered Access is denied while resolving the hooks path. I’ve confirmed that my original “hook discovery was unresolved” wording was too broad; I don’t currently have evidence of a general issue or regression in #2052. The note was only intended to explain why that PR had no genuine checkpoint trailer.