codegraph_explore concurrent calls are very slow in non-daemon (direct stdio) mode

[blabla-yy]

Setup

• CodeGraph 1.5.0
• Several repos (one of them ~20,000 Java files)
• Running codegraph serve --mcp --no-watch directly (not using the shared
  daemon), single stdio connection. I point one long-lived
  codegraph serve --mcp --no-watch process at each codegraph_explore
  call via the projectPath argument, instead of running a separate
  daemon (with its own watcher) per repo.

Observed

A single codegraph_explore call takes ~5s. When several explore calls
run concurrently on this same connection, each one slows down to tens of
seconds — latency grows roughly with the number of concurrent calls, similar
to what's described in #987.

Question

#1002 fixed this for shared-daemon mode via CODEGRAPH_QUERY_POOL_SIZE, but
says direct/single-stdio-client mode is unchanged (no pool). Since I'm
intentionally running without the daemon, does CODEGRAPH_QUERY_POOL_SIZE
have any effect here? Is there a way to get worker-thread parallelism for
concurrent explore calls without adopting the shared-daemon setup?

Also — v1.5.0's Rust kernel covers parse/extraction. Since explore itself
is confirmed CPU-bound, is a native/Rust rewrite of the query execution path
on the roadmap? And is there a public roadmap I can follow?