[BUG] Post search filter logic doesn't re-validate the vector field.

[allenss-amazon]

Describe the bug
The post-search filter logic which ensures that false-positive hits in the index are re-validated against current data doesn't include checking whether the vector field has been modified.

To Reproduce
Arrange to modify a vector field of a key after it's been searched but before the result filtering logic has completed. You'll get the wrong answer.

Expected behavior
The post-search filter logic should validate that the vector field is still the same and if not, re-score the vector and potentially modify it's position in the distance table.

Environment

Additional information to reproduce the failure

• Valkey Search Module Version
• Valkey Core Version

Additional context
Add any other context about the problem here.

[zvi-code]

This came up in some internal discussion. I wanted to note that recomputing vector distances would be very expensive - you'd need to re-rank all candidates to determine if a changed vector should still be in TopK results. Also worth mentioning that in NOCONTENT mode we don't perform any post-search verification at all, so adding this check could add significant performance impact on the main thread.

I'd suggest viewing the additional filtering check as a user experience feature rather than a consistency guarantee - it's there to avoid returning field values that contradict the filter criteria (e.g., filtering for @player_type:{free} but returning @player_type:{pro}). IMO this makes sense for fields that it would take O(1) to verify vs a filter. Happy to discuss if helpful.

[yairgott]

Although I agree with the concern about consuming the main thread, this operation should be handled by a reader thread.The existing thread pool architecture already supports executing arbitrary job types.