[Bug] First Gremlin query can poison ConditionQuery initialization #3300

Problem

The first label-filtered Gremlin request on a fresh Server can fail with Not allowed to access system property(java.version) via Gremlin. ConditionQuery creates Gson during static initialization; Gson's JavaVersion reads that restricted property on the Gremlin worker. The failed class initialization leaves later queries unusable for the rest of that JVM.

Evidence and reproduction

The original report records a fresh Server's first hasLabel() Gremlin returning 403 and a subsequent REST label query returning 500 with Could not initialize class org.apache.hugegraph.query.ConditionQuery. The report also reproduces the issue on the pre-Topling base.

Apache master 68855199031d5801edb4fe41b2bacbacffe8fe68 still constructs Gson in ConditionQuery.<clinit> without explicit query initialization before accepting requests. A fresh-JVM Java 17 fixture with the real Gremlin engine independently reproduces the ConditionQuery -> Gson -> JavaVersion -> HugeSecurityManager failure when startup query initialization is omitted. The fixture exercises Java query construction reached from a script; it is separate from the reported full HTTP deployment.

Expected behavior

Complete query/serializer initialization on a trusted startup thread before REST or Gremlin accept requests. The first graph query should need no preceding REST warmup. Scripts that directly read restricted properties or disable the security manager must remain rejected.

Existing work checked

Searched Apache and community issues/PRs for ConditionQuery initialization, Gson, cold Gremlin and the exact property error. #3228 concerns graph binding after a PD connectivity failure; #3221 concerns readiness. Neither fixes this initialization failure, and no active dedicated fix was found.