[Improve] Align struct ConditionQuery resolution with server semantics

Compare the server implementation in hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/backend/query/ConditionQuery.java with hugegraph-struct/src/main/java/org/apache/hugegraph/query/ConditionQuery.java, then inspect Store's FilterIterator and FilterStage. Add the separated resolution behavior and tests for the listed condition cases, while preserving legacy condition() behavior and verifying Store compatibility without a wire-format change.

Background

Follow-up to PR #2994 review, inspected at 2d53a556c001a13f5efafffc70cc60bee8b15496.

HugeGraph has two ConditionQuery implementations:

• Server: hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/backend/query/ConditionQuery.java.
• Distributed components: hugegraph-struct/src/main/java/org/apache/hugegraph/query/ConditionQuery.java, deserialized by Store's FilterIterator and FilterStage.

PR #2994 separates condition presence, candidate intersection, strict single-value resolution, and tolerant single-value resolution in the server implementation. The struct copy retains the legacy accessor and uses an empty intersection as its initialization sentinel.

For three top-level relations on the same key, that sentinel loses a conflict:

An initialized intersection must remain empty after a conflict. At the inspected head, a search of struct/store finds no production call to this condition(Object) accessor; the similarly named calls are Condition.Not.condition(). This is a dormant semantic divergence, not evidence that current Store filtering returns incorrect results.

Scope and acceptance

• Port the server's collectConditionValues / resolveConditionValues separation and explicit initialization state to struct.
• Align explicit presence, candidate-set, strict-singleton, and tolerant-singleton accessors, while documenting any intentional API difference.
• Preserve the documented legacy condition() behavior, including a sole raw IN value; fix conflict reseeding without silently changing unrelated predicate evaluation.
• Test absent conditions, empty IN, singleton/multi-value candidates, duplicate values, mixed EQ/IN, non-EQ/IN relations, and conflicts in different orders with at least three relations.
• Check parity with server fixtures and verify Store deserialization/filtering remains compatible. No wire-format change is intended.
• Keep cross-references on both copies so future semantic changes are checked together.

The struct implementation and its tests belong in a separate change from PR #2994. Traversal pushdown and the local CONTAINS cache tracked in #3196 are out of scope.