fix(hgraph): backport duplicate query handling to 1.0 - #2944

[suggestion] The add_pending_duplicates lambda checks group_id != group_member_id and returns early, while add_duplicate_results in the non-iterator path passes group_member_id directly to GetDuplicateIds without this check. This asymmetry means the iterator path only expands duplicates when visiting the representative node, while the non-iterator path expands duplicates for any node. If GetDuplicateIds returns the same group regardless of which member is queried (i.e., it internally resolves to the representative), then the group_id check in add_pending_duplicates is redundant. If GetDuplicateIds requires the representative ID, then add_duplicate_results should also resolve the group representative first.

Please clarify the intended semantics and align both paths.

[note] In the entry-point initialization path, add_pending_duplicates(dist, ep) is called unconditionally (position 74), but the original lower_bound update was also moved inside the if (not top_candidates->Empty()) guard. If ep is filtered out and its duplicates are added via add_pending_duplicates but then all evicted by shrink_top_candidates, top_candidates may become empty while lower_bound retains a stale value. Consider whether lower_bound should be reset to a sentinel (e.g. std::numeric_limitsts<float>::max()) when top_candidates is empty after this block, to prevent the subsequent search loop from using an incorrect lower bound.

[suggestion] The add_duplicate_results lambda in parallel_searcher.cpp (and the equivalent in basic_searcher.cpp non-iterator path) calls graph->GetDuplicateIds(group_member_id) directly without resolving the group representative first. This differs from add_pending_duplicates which checks graph->GetGroupId(group_member_id) != group_member_id and returns early if the node is not the representative.

If GetDuplicateIds is only meaningful when called with the representative ID, both add_duplicate_results implementations should resolve the group representative first (e.g., via graph->GetGroupId). Otherwise, if GetDuplicateIds handles non-representative IDs gracefully, the check in add_pending_duplicates is unnecessary and can be removed for consistency.

See the related comment on basic_searcher.cpp for the same issue.

[note] In the is_last_filter drain path, pending duplicates are pushed to search_result before the discard heap is drained (lines 121-128), and pending-duplicate entries in the discard heap are skipped (lines 133-135). After both loops complete, the pending_duplicates_ map still contains the drained entries. While SetPoint clears individual entries when they are later marked as visited, the map itself is not cleared after the final drain. This is harmless for correctness since the iterator context is typically discarded after the last page, but if the context were reused (e.g., for a new query with the same iterator), stale pending entries could interfere. Consider calling a ClearPendingDuplicates() or resetting pending_duplicates_ after the final drain for robustness.

[suggestion] The validation for max_duplicates_per_group checks IsNumberUnsigned() and validates the uint64 value against int64_t::max(), then calls GetInt() which returns int64_t. However, if the JSON value is a negative integer (e.g., -1), IsNumberUnsigned() returns false and the range check is skipped, which is correct. But if the JSON value is a large unsigned integer just below int64_t::max(), GetInt() should handle it correctly since the range check ensures it fits in int64_t. This logic is sound, but consider adding a comment explaining why the unsigned path is needed (to catch large unsigned values that would overflow int64_t), as the flow is not immediately obvious to a reader.