Declare equals/hashCode consistent with compareTo (CodeQL java/inconsistent-compareto-and-equals)

[vharseko]

Summary

Resolves all three open java/inconsistent-compareto-and-equals CodeQL alerts
in the persistit engine. Each flagged class implements Comparable/compareTo
but inherited Object.equals, so equals and compareTo could be
inconsistent:

Class	compareTo orders by	Used in
BufferPool.BufferHolder	volumeId, page	Arrays.sort
JournalManager.TransactionMapItem	commit / start timestamp	TreeSet, sorted List
TreeBuilder.Node	tree order, key	TreeMap<Node, Node>

Why it is safe

None of these types is currently compared through equals/hashCode:

• the sorted collections (TreeMap, TreeSet, Arrays.sort,
  Collections.sort) all use compareTo, not equals;
• the types are never placed in a hash collection keyed by themselves
  (TransactionMapItem is only a value in a HashMap<Long, …>), and
• there is no contains / indexOf / remove(Object) call that would invoke
  equals on them.

So the inconsistency was latent rather than an active bug, but it is exactly
the trap this rule guards against for future callers.

Fix

For each class, declare equals and hashCode consistent with the existing
compareTo:

• equals(o) returns true iff o is the same reference or compareTo(o) == 0;
• hashCode is derived from the same ordering key
  ((volumeId, page); commit-or-start timestamp; the tree instance for a
  Node).

Because nothing relied on the inherited identity equals, behaviour is
unchanged for every existing usage.

Also adds the missing Portions Copyrighted 2026 3A Systems, LLC header line
to JournalManager.java (TreeBuilder.java and BufferPool.java already
carry it).

Testing

mvn -o -pl persistit/core -am compile — BUILD SUCCESS.