[Improve] Avoid per-element condition resolution in LocalContainsStep

### Background

Follow-up to [PR #2994 review](https://github.com/apache/hugegraph/pull/2994#discussion_r3955850541), 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](https://github.com/apache/hugegraph/blob/e32a75ff85a30ab105afba745a82d4600e31c3b3/hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/traversal/optimize/TraversalUtil.java#L842-L872).

Example workload, with `age` defined in the graph schema:

```groovy
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.

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.

Written by the indexing model from the issue text.