Fixes #13108

Problem

In groupBy queries, minDistance and maxDistance describe the minimum and maximum distances of the group's hits. Two execution paths compute or assign them incorrectly:

1. Multi-shard group merge (adapters/repos/db/group_merger.go):
   After hits from all shards are merged and sorted ascending by distance (hits[i].Distance < hits[j].Distance), MaxDistance was assigned hits[0] (the lowest distance) and MinDistance was assigned hits[len(hits)-1] (the highest distance). For multi-shard queries, this inverted minDistance and maxDistance (minDistance > maxDistance).
2. Hybrid search group by (usecases/traverser/hybrid_group_by.go):
   In groupSearchResults, both MinDistance and MaxDistance were assigned first.Dist, copying only the first hit's distance and ignoring all other members of the group. Since hybrid search ranks hits by fusion score (not pure distance), first.Dist does not represent the minimum or maximum distance of the group.

Solution

• In adapters/repos/db/group_merger.go: Assign MinDistance from hits[0] (smallest distance) and MaxDistance from hits[len(hits)-1] (largest distance).
• In usecases/traverser/hybrid_group_by.go: Iterate over all retained groupMembers to compute the minimum and maximum hit distances for the group.
• Added comprehensive unit tests in adapters/repos/db/group_merger_test.go and usecases/traverser/hybrid_group_by_test.go covering multi-shard merges, ObjectsPerGroup capping, group ordering, and hybrid search distance tracking.

Verification

• go test -v -run TestGroupMerger ./adapters/repos/db passes.
• go test -v -run TestExplorerGroupSearchResults ./usecases/traverser passes.