fix: fix equal bug in some files

[enkilee]

Which Issue(s) This PR Fixes

• Fixes #issue_id

Brief Description

compareTo 与 Object.equals 共存.
在 TreeSet/TreeMap 中，compareTo 返回 0 的两个对象会被视为"相等"但 equals() 返回 false，违反 Comparable 契约，可能导致集合中元素丢失或行为不一致。
修复：重写 equals/hashCode 与 compareTo 一致。

How Did You Test This Change?

[RockteMQ-AI]

Code Review

This PR adds equals() and hashCode() implementations to 7 classes that implement Comparable but were missing proper equality methods.

Overall Assessment: ✅ Generally good, with minor suggestions

Changes Reviewed:

• TraceContext.java - Uses timeStamp for equality
• GrpcClientChannel.java - Uses clientId for equality
• RemoteChannel.java - Uses id for equality
• PopCheckPoint.java - Uses startOffset for equality
• FileSegment.java - Uses baseOffset for equality
• GroupConsumeInfo - Uses count + diffTotal for equality
• TagCountBean - Uses tag for equality

Observations:

1. Consistency with compareTo(): Most implementations align equality fields with compareTo(), which is good practice. However, note that TraceContext uses only timeStamp while compareTo() also uses timeStamp — this is consistent.

2. Null handling: GrpcClientChannel and TagCountBean properly handle null values in equals() and hashCode(). Good.

3. Potential issue in GroupConsumeInfo: The compareTo() uses diffTotal - diffTotal (subtraction), but equals() uses field comparison. This is acceptable, but ensure the class is not used in sorted collections where compareTo() returning 0 should imply equals() returning true.

4. Missing Objects.equals(): Some implementations use manual null checks instead of Objects.equals(). Consider using:

   return Objects.equals(this.tag, that.tag);

Suggestion: Consider adding unit tests to verify the equals()/hashCode() contracts (reflexive, symmetric, transitive, consistent).

---

Review by @RockteMQ-AI