Make the Go/SQL tally parity a tested contract, not a hand-maintained one

Gadfly's point stands: countRevisions reproduces in Go what ListChangeSets does
in SQL, and nothing was holding the two together. Its sibling finding is the
same problem seen from the test side — the test compared only TOTALS, which
would agree even if the two groupings had diverged completely.

Both ends now name the contract, and the test compares the full per-(entity, op)
breakdown row for row, across two reverts of different shapes so there is more
than one row to get wrong. That turns "someone will remember to keep these in
step" into something CI notices.

The duplication itself stays. A change set that has just been written has no
rows to GROUP BY yet, so the alternative to counting in Go is a second round
trip to count what we are already holding.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ

internal/service/revisions.go

@@ -346,9 +346,13 @@ func (s *Service) RevertChangeSet(ctx context.Context, actorID, changeSetID int6
 	return cs, conflicts, nil
 }
 
-// countRevisions tallies revisions by (entity type, op), matching what the
-// history list read produces so both sides of the API describe a change set the
-// same way.
+// countRevisions tallies revisions by (entity type, op).
+//
+// This deliberately reproduces in Go what ListChangeSets does in SQL, because a
+// change set that has just been written has no rows to GROUP BY yet — the
+// alternative is a second round trip to count what we are already holding.
+// The parity is a real cross-layer contract, and TestRevertResultCarriesItsCounts
+// compares the two breakdowns row for row so it can't drift silently.
 func countRevisions(revs []domain.Revision) []domain.ChangeCount {
 	type key struct{ entityType, op string }
 	seen := map[key]int{}