[Improve] Align struct ConditionQuery resolution with server semantics

### Background

Follow-up to [PR #2994 review](https://github.com/apache/hugegraph/pull/2994#discussion_r3972183217), 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:

| Relation processed | Struct intersection |
| --- | --- |
| `EQ a` | `{a}` |
| `EQ b` | `{}` |
| `EQ c` | `{c}`, incorrectly reseeded |

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.

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.

Written by the indexing model from the issue text.