fix(status): pin the aligned ownership vote in the push-disabled status test

[peyton-alt]

https://entire.io/gh/entireio/cli/trails/1315

Summary

Main's Tests workflow has been red since #2342 merged on top of #2337: TestRunStatus_CheckpointPushDisabledDestinations/{git-branch,git-refs}/dedicated_rejected_by_fetch_owner fails at every commit from e8780c3 onward and passes at its parent.

• fix(status): report disabled checkpoint pushing #2337 added a row asserting the read-side ownership vote counts the elected candidate's fetch URL while the push side counts its push URLs, so a fork fetching from other but pushing to org had writes accept the dedicated store and reads reject it.
• fix: preserve selected remote when fetching checkpoint refs #2342 (adc64ce65, "align the fetch-side ownership vote with the push side") deliberately made both votes use origin plus the candidate's push URLs, so reads land where writes went. That row now correctly resolves to the dedicated store.

This PR updates the test to the new semantics rather than reverting either change:

• Replaces dedicated_rejected_by_fetch_owner with two rows pinning the aligned vote in both directions: dedicated_accepted_by_push_owner (fetch other, push org → dedicated store) and dedicated_rejected_by_push_owner (fetch org, push other → elected remote, store reported as not in use).
• Rewrites the two status.go comments that still described the asymmetric vote. The read-side "not in use" branch is kept: ReadsDedicatedStore can still decline for non-ownership reasons (unparseable origin URL, unmappable protocol) that the push-side verdict never considers.

No behaviour change.

Test plan

• go test ./cmd/entire/cli/ -run 'Status|CheckpointSync|Topology|Doctor' passes
• mise run lint:go — 0 issues
• CI Tests workflow green on this branch

Once merged, #2078 and #2361 (currently failing only on this test) go green after merging main again.

🤖 Generated with Claude Code

---

Note

Low Risk
Comment and test-only updates; no production logic changes.

Overview
Fixes CI breakage after #2342 aligned push- and read-side checkpoint_remote ownership checks: both now vote over origin plus the candidate’s push URLs (not the fetch URL), so reads match where writes go.

Tests: Replaces the obsolete dedicated_rejected_by_fetch_owner table row with dedicated_accepted_by_push_owner (fetch from another owner, push to the store owner → dedicated read source) and dedicated_rejected_by_push_owner (the mirror case → elected remote + “not in use” warning). Updates inline comments in the push-disabled destination test to match.

Docs in code: Rewrites computeCheckpointSyncInfo comments in status.go to describe the shared identity set and to clarify that the push-disabled “not in use” branch still covers non-ownership read declines (unparseable origin, unmappable protocol).

No runtime behavior change — expectations and commentary only.

^{Reviewed by Cursor Bugbot for commit dbaa7e7. Configure here.}

[Copilot]

🟡 Changes recommended

Several comments still describe the obsolete fetch/push ownership asymmetry.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

This PR updates status regression tests and comments to reflect aligned checkpoint ownership checks using push URLs, with no production behavior changes.

Changes:

• Replaces the obsolete ownership test with accepted and rejected push-owner cases.
• Updates status and fixture documentation.
• Preserves coverage for non-ownership read failures.

File summaries

File	Summary
cmd/entire/cli/status.go	Documents aligned ownership semantics and non-ownership read failures; remaining comments need updates.
cmd/entire/cli/status_test.go	Adds both push-owner regression cases; the adjacent fixture comment needs updating.

Review details

Suppressed comments (2)

cmd/entire/cli/status.go:539

• This update still leaves the preceding comment at lines 523–526 saying that the fetch side votes with the read candidate and that push-only owner mismatches can diverge. That contradicts the aligned ownership semantics documented in this new block (and implemented by ReadsDedicatedStore), so a future maintainer can still be directed toward the old behavior; please update that adjacent comment to describe only the remaining non-ownership read declines.

			// That verdict is ownership only, so it accepts a store the fetch
			// side declined for another reason (an unparseable origin URL, an
			// unmappable protocol) — and with pushing disabled the fetch side
			// is the one that decided the line above. Without this the
			// configured store is reported by nothing at all, which is the
			// silent-ignore the warning exists to prevent. Ownership itself
			// cannot split the two: both vote over origin plus the
			// candidate's push urls.

cmd/entire/cli/status.go:479

• The resolveDedicatedReadSource doc above this hunk still says the lead FETCH URL joins origin in the ownership vote and that the function exists to remove an asymmetry. After #2342, fetchOwnershipURLs uses the lead remote's PUSH URLs, so this new explanation now contradicts that function contract; please update the doc comment to match the aligned vote.

	// which is the fetch side's call. Both sides vote ownership over the same
	// identity set — origin plus the candidate's PUSH urls, never its fetch
	// url, so reads land where writes went — but the read side can still
	// decline a store for reasons the push side does not consider (an origin
	// URL that will not parse, a protocol with no checkpoint mapping), so
	// asking the wrong side can report a store reads do not use.

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.