MINOR: Follow-up KAFKA-20696

[frankvicky]

Deal the comments of #22622

• OffsetMetadataManager.allOffsetsExpired → groupHasNoOffsets.
  Per-topic / per-partition expiration check was O(topics × partitions)
  per group. Since the regular offset-expiration cycle already tombstones
  expired offsets, this stage only needs the post-state — a single
  null-check on offsetsByGroup plus an openTransactions.contains
  (O(1)). Three cycles compose cleanly: offset expiration → topology
  cleanup → group tombstone. The now-unused snapshot overload
  OpenTransactions.contains(groupId, topic, partition, committedOffset)
  is removed.

• Per-shard batching of the conditional clear write. All groups in
  one partition's eligibility read hash to the same __consumer_offsets
  partition, so the cycle now issues one scheduleWriteOperation per
  shard carrying every conditional clear for that shard — not one write
  per group. Added
  GroupCoordinatorShard.clearStoredDescriptionTopologyEpochBatch(Map<String, Integer>) that folds per-group GMM results into one
  CoordinatorResult.

• Restored inline comment on the pending-transactional-offset guard
  in cleanupExpiredOffsets — accidentally dropped during the
  helper-extract / inline round-trip.

Reviewers: Alieh Saeedi asaeedi@confluent.io

[frankvicky]

Deal withs the new comments from #22622 (comment) after merge.

[aliehsaeedii]

Thanks @frankvicky. I left some minor comments.

[aliehsaeedii]

The batch's target partition is derived from keySet().iterator().next(), which throws NoSuchElementException on an empty map. It's safe today because the only caller guards with if (toClear.isEmpty()), but that coupling is implicit. Consider an early if (expectedStoredEpochByGroupId.isEmpty()) return CompletableFuture.completedFuture(null); here so the method is self-protecting and doesn't depend on the caller's guard staying in place.

[aliehsaeedii]

The batched failure log now reports size() + partition instead of the individual groupId, so a failed write no longer tells you which groups didn't get cleared. Given the next-cycle retry guarantee this is acceptable, but logging the group ids (here or at debug) would make a stuck group easier to diagnose.