AgentEvaluator.evaluate() fails a lower-is-better metric whose evaluator reports PASSED

Finding: In google/adk-python, AgentEvaluator.evaluate() is reported to mark a custom lower-is-better metric as FAILED even when the evaluator itself reports PASSED, if the score is below the configured threshold. The reporter saw this on origin/main commit 6be386d8 and on released google-adk 2.11.0 (Python 3.11, Windows 11) [issue #7414](https://github.com/google/adk-python/issues/7414). This is an external report; KFA has not reproduced it. Reported scenario: a toy evaluator for an error_rate metric returns score 0.1 with PASSED status, and the criteria threshold is 0.5. The run prints a summary that the metric is FAILED with expected threshold 0.5 and actual 0.1, even though the per-invocation table shows PASSED. evaluate() then raises an AssertionError beginning "Following are all the test failures." The reporter says it happens every time ([issue #7414](https://github.com/google/adk-python/issues/7414)). Reported cause (hypothesis, not maintainer-confirmed): the reporter says _process_metrics_and_get_failures decides pass/fail with overall_score >= threshold, after the INFORMATIONAL branch, without consulting the metric's own eval_status. The thread contains no maintainer statement confirming this cause. Mitigation status: the reporter says setting the metric to EvalStatus.INFORMATIONAL avoids the false failure but removes gating, so a value above the limit (e.g. 0.9) would also pass. It is therefore not an adequate workaround if the metric must be able to fail a run ([issue #7414](https://github.com/google/adk-python/issues/7414)). Fix status: the reporter says PR #6739 implements a fix. A collaborator said the PR is under review and asked for merge conflicts to be resolved. The contributor then said the conflicts were resolved against a change adding the INFORMATIONAL early-exit and threshold lookup, and that the changed tests pass locally ([issue #7414](https://github.com/google/adk-python/issues/7414)). The supplied sources show no merge, fix commit, or release containing the fix, so treat it as unfixed. Practical implication: if you rely on custom lower-is-better metrics with evaluate(), expect a score under the threshold to count as a failure regardless of the evaluator's verdict in the affected versions. Check whether the PR has merged and shipped before depending on evaluator-status semantics. This record relies solely on the issue thread, and the cause and fix details are unverified by KFA.