Synchronize overrides of synchronized methods (CodeQL java/non-sync-override)

[vharseko]

Summary

Resolves all four open java/non-sync-override CodeQL alerts. Each method
overrode a synchronized method from java.io.InputStream or
java.lang.Throwable but dropped the synchronized modifier, so a caller that
relies on the base-class locking contract silently loses it on these subtypes.
The fix restores the modifier on each override.

File	Method	Overrides
ByteArrayBranchingStream.java (105)	mark	InputStream.mark
Value.java (5059)	mark	InputStream.mark
Value.java (5064)	reset	InputStream.reset
PersistitMap.java (744)	getCause	Throwable.getCause

Why it is safe

• ByteArrayBranchingStream.mark — the class already declares read,
  skip, available and reset as synchronized, and they all read/write the
  shared position / mark fields. mark was the one method mutating mark
  from position without the lock, so adding synchronized simply makes it
  consistent with its siblings.
• Value.OldValueInputStream.mark / reset — this is the
  ObjectInputStream used to decode a Value; both methods touch the shared
  _mark / _value._next cursor. Synchronizing restores the InputStream
  contract.
• PersistitMap.PersistitMapException.getCause — restores the
  Throwable.getCause contract for this unchecked wrapper.

Every one of these methods only reads or writes its own instance fields and
calls nothing that takes another lock, so adding synchronized cannot introduce
a lock-ordering deadlock. Single-threaded callers see no behavioural change.

Testing

mvn -o -pl commons/http-framework/core,persistit/core -am compile — BUILD SUCCESS.