[Improve] Avoid per-element condition resolution in LocalContainsStep

Start with hugegraph-core/src/main/java/org/apache/hugegraph/traversal/optimize/TraversalUtil.java, especially LocalContainsStep and convContains2Relation(), and review PR #2994 at the referenced commit. Establish cache lifetime and invalidation behavior before implementing; then add coverage for reuse, lifecycle changes, serialization, schema recreation, and filtering boundaries. Done includes consistent results and reported allocation and timing comparisons.

Background

Follow-up to PR #2994 review, inspected at commit e32a75ff85a30ab105afba745a82d4600e31c3b3. This is a separate performance task; PR #2994 will keep the existing CONTAINS implementation in this revision.

TraversalUtil.LocalContainsStep evaluates local has(T.key, ...) and has(T.value, ...) filters when predicates cannot be pushed into the backend. Its filter() loads an element's properties and invokes convContains2Relation() for each candidate. For a string property key, the conversion resolves graph.propertyKey(name) and allocates a new Condition on every call. A large fallback scan therefore repeats schema resolution and allocation for the same predicate.

Source: LocalContainsStep and conversion helper.

Example workload, with age defined in the graph schema:

g.V().has(T.key, 'age').hasLabel(P.neq('excluded')).toList()

The repeated work is confirmed by source inspection. Its latency/allocation impact has not been benchmarked, and this comment does not establish a wrong-result defect.

Proposed scope

Resolve and reuse the converted condition within a valid execution context instead of rebuilding it for each candidate. Choose the cache lifetime and invalidation rules before implementing it; graph identity alone does not account for schema removal/recreation within the same graph.

Keep runtime graph resolution, lazy property loading via getFilledProperties(), and the HasStep boundary that prevents count/range optimization from bypassing filtering. Do not capture a transaction, element, iterator, or a graph during strategy application. Broader negative-label pushdown and coverage-report collection are out of scope.

Acceptance criteria

• Repeated candidates on an unchanged graph/predicate reuse the conversion, with a test that counts schema resolutions or conversions.
• Tests cover reset/re-execution, cloning, graph rebinding, predicate/container changes, and serialization before and after cache use.
• Same-graph schema removal/recreation cannot reuse stale property-key IDs; document and test the chosen invalidation behavior.
• Result and error behavior remain consistent for key/value filters, missing properties, unsupported predicates, lazy adjacent vertices, count, range, and paging boundaries.
• Compare allocation and execution time on identical builds/data apart from this change, including a large local-filter scan and a small ID/adjacency query. Report measured results without assuming a speedup.