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/store/revisions.go

@@ -119,7 +119,9 @@ func (d *DB) ListChangeSets(ctx context.Context, gardenID int64, limit, offset i
 		return sets, nil
 	}
 
-	// One grouped query for the whole page rather than N per-row counts.
+	// One grouped query for the whole page rather than N per-row counts. The
+	// service's countRevisions mirrors this grouping for change sets it has just
+	// written; TestRevertResultCarriesItsCounts holds the two in step.
 	countRows, err := d.sql.QueryContext(ctx,
 		`SELECT change_set_id, entity_type, op, COUNT(*)
 		   FROM revisions