Rename Go-style method names in production code (16 offenders)

Checkstyle's MethodName flags 16 methods in src/main that don't match ^[a-z][a-zA-Z0-9]*$. They split into two groups, and the right fix differs.

Group 1 — public APIs that need a real rename (4)

These are public symbols other callers depend on. Each rename is a breaking change; either land with a deprecation shim if we care about source compatibility, or take the clean break.

• Metrics.Clear() → clear() — already shipped in PR #70
• NoOpMetrics.Instance() → instance() (opa-evaluator/src/main/java/io/github/open_policy_agent/opa/metrics/NoOpMetrics.java:11)
• QueryTracer.TraceEvent(Event) → traceEvent(Event) (opa-evaluator/src/main/java/io/github/open_policy_agent/opa/tracing/QueryTracer.java:6)
• BufferedQueryTracer.TraceEvent(Event) → traceEvent(Event) (opa-evaluator/src/main/java/io/github/open_policy_agent/opa/tracing/BufferedQueryTracer.java:20)

Group 2 — builtin implementations using OPA's snake_case (12)

These mirror Rego/OPA builtin names; renaming them would diverge from upstream.

• ArithmeticBuiltins: ceil_f, round_f, floor_f, abs_f
• JsonBuiltins: marshal_with_options, is_valid, match_schema, verify_schema
• TokenBuiltins: _verifyECDSA, _verifyEdDSA, _verifyRSASSA, _verifyHMAC (all private)

Decision needed: rename to camelCase, or suppress MethodName on **/ast/builtin/impls/** so the builtin code can stay aligned with OPA's naming?

My read: suppress MethodName for *Builtins.java (matches OPA's surface), rename Group 1 (Java callers, no upstream alignment argument).

Start with NoOpMetrics.java and the QueryTracer.java and BufferedQueryTracer.java declarations, then search for callers of the public methods before choosing whether to preserve compatibility. Review the ArithmeticBuiltins, JsonBuiltins, and TokenBuiltins methods alongside the Checkstyle MethodName configuration. Done means the four public names and the twelve builtin violations follow the chosen policy without unresolved MethodName failures.