JdbcSnapshotStore ignores minSequenceNr and minTimestamp from SnapshotSelectionCriteria

Suggested by Claude.
This issue does not exist in pekko-persistence-r2dbc.
I wonder if the pekko-persistence-jdbc component has been quietly sidelined in favour of pekko-persistence-r2dbc.

Pekko's SnapshotSelectionCriteria has four fields: maxSequenceNr, maxTimestamp, minSequenceNr, and minTimestamp. The JdbcSnapshotStore in pekko-persistence-jdbc pattern-matches on only the first two (max bounds) and silently discards the min bounds. This affects both loadAsync and deleteAsync.

Affected file: core/src/main/scala/org/apache/pekko/persistence/jdbc/snapshot/JdbcSnapshotStore.scala

Current behavior (lines 68-78 for load, 92-102 for delete):

// loadAsync - only uses maxSequenceNr and maxTimestamp
criteria match {
case SnapshotSelectionCriteria(Long.MaxValue, Long.MaxValue, _, _) => // min fields discarded via _
snapshotDao.latestSnapshot(persistenceId)
case SnapshotSelectionCriteria(Long.MaxValue, maxTimestamp, _, _) =>
snapshotDao.snapshotForMaxTimestamp(persistenceId, maxTimestamp)
case SnapshotSelectionCriteria(maxSequenceNr, Long.MaxValue, _, _)
snapshotDao.snapshotForMaxSequenceNr(persistenceId, maxSequenceN
case SnapshotSelectionCriteria(maxSequenceNr, maxTimestamp, _, _) =>
snapshotDao.snapshotForMaxSequenceNrAndMaxTimestamp(persistenceId, maxSequenceNr, maxTimestamp)
case _ => Future.successful(None)
}

The _, _ wildcards explicitly ignore minSequenceNr and minTimestamp. The DAO methods and SQL queries have no parameters for min bounds at all.

Impact:
- loadAsync may return a snapshot that is below the caller's minimumamp
- deleteAsync may delete snapshots that fall below the minimum boundr intended to keep
- Any Pekko application relying on min-bounds filtering (e.g., SnapsquenceNr, maxTimestamp, minSequenceNr = 5, minTimestamp = ...)) gets
incorrect results

Note: The Pekko TCK (SnapshotStoreSpec) does not test min bounds, so this bug passes CI undetected.

---
Plan for Changes

Files to modify (7 files):

1. SnapshotDao.scala — Add two new methods with default implementatility:
- snapshotForCriteria(persistenceId, maxSequenceNr, maxTimestamp, minSequenceNr, minTimestamp) — defaults to existing max-only methods
- deleteByCriteria(persistenceId, maxSequenceNr, maxTimestamp, minSequenceNr, minTimestamp) — defaults to existing max-only methods
2. SnapshotQueries.scala (new schema) — Add query builders that cond filters (sequenceNumber >= minSequenceNr when > 0, created >=minTimestamp when > 0) alongside the existing max-bounds filters.
3. DefaultSnapshotDao.scala — Override the new methods to use the new query builders.
4. legacy/SnapshotQueries.scala — Same query builder additions for t
5. legacy/ByteArraySnapshotDao.scala — Override the new methods for legacy DAO.
6. JdbcSnapshotStore.scala — Replace the pattern-matching dispatch ic with direct calls to snapshotForCriteria and deleteByCriteria,passing all four bounds from the criteria.
7. JdbcSnapshotStoreSpec.scala — Add directional tests:
- loadAsync with minSequenceNr excludes snapshots below the min
- loadAsync with minTimestamp excludes snapshots below the min
- deleteAsync with minSequenceNr preserves snapshots below the min
- deleteAsync with minTimestamp preserves snapshots below the min

Binary compatibility:

- New methods on SnapshotDao trait are concrete with default implementations → binary compatible (Java 8+ default interface methods)
- Existing methods remain unchanged
- MiMa should pass cleanly

Start with core/src/main/scala/org/apache/pekko/persistence/jdbc/snapshot/JdbcSnapshotStore.scala and trace the SnapshotDao, DefaultSnapshotDao, SnapshotQueries, legacy/SnapshotQueries, and legacy/ByteArraySnapshotDao paths. Run JdbcSnapshotStoreSpec.scala, then add coverage showing loadAsync respects minimum sequence and timestamp bounds and deleteAsync preserves snapshots below them.

Written by the indexing model from the issue text.