Summary:
There are 2 scenarios when we iterate over options in HybridScanChoices.
1) Fetched current row and should move to the next one.
2) Found row that does not satisfy current options.

When bloom filters are used we update upper bound after options update.
But it could happen that we already iterated over all options, and update upper bound should be skipped.
Such situation was correctly handled in (1), but was not handled in (2).

This diff adds necessary logic to handle it in (2).
Jira: DB-18674

Test Plan: ./yb_build.sh debug --java-test org.yb.pgsql.TestPgRegressJoin#testPgRegressJoin

Reviewers: patnaik.balivada

Reviewed By: patnaik.balivada

Subscribers: ybase

Tags: #jenkins-ready

Differential Revision: https://phorge.dev.yugabyte.com/D47501