Propagate request context across JDK executors

[Mishenevd]

Second of the stack, on top of #342 — this is where the primitives get used.

We weave the JDK executor types so a task submitted from a request thread runs with that request's context on the pool worker: ThreadPoolExecutor, ForkJoinPool, AbstractExecutorService, ScheduledThreadPoolExecutor and the Executors$Delegated* services. In practice that covers @Async, CompletableFuture, plain thread pools and scheduled tasks — all of which used to lose the context on the hop and silently miss attacks in the async path.

Two loading strategies, on purpose:

• ThreadPool/ForkJoin/AbstractExecutorService go through a cached reflection bridge (ExecutorContextPropagation).
• ScheduledThreadPoolExecutor and the delegated executors load agent_api per call via a short-lived URLClassLoader. They run early during class loading, where the cached bridge deadlocks, so the per-call loader is required here — and it's now closed after wrapping.

ExecutorWrapperTest covers this with 9 integration tests under the woven agent: propagation across every executor type plus CompletableFuture, nested submits, two concurrent tasks each keeping their own context, a pooled worker not leaking context into the next task, and the no-context passthrough.

[aikido-pr-checks]

🟡 Medium - Bootstrap executor advice calls an agent-only helper that JDK classes cannot resolve

The new AbstractExecutorService, ThreadPoolExecutor, and ForkJoinPool advices inject direct calls to ExecutorContextPropagation.wrap(...) into java.util.concurrent classes even though this JVM setup never injects agent helper classes into the bootstrap classloader. The project already handles bootstrap-loaded JDK wrappers via reflective loading for that reason, and these advices also suppress any linkage error, so submit/execute on core executors silently runs without propagated request context. As a result, async work scheduled onto common JDK executors loses the request metadata that Zen uses to attribute and enforce protections on downstream sinks.

Show fix

Do not reference dev.aikido.agent... helpers directly from advice woven into bootstrap-loaded JDK classes. Either move these executor wrappers to the same reflective bridge pattern already used for bootstrap JDK wrappers, or explicitly append the helper classes to the bootstrap classloader search before instrumenting java.util.concurrent so the injected calls can actually resolve.

_{More info - Reply on this comment to give feedback or ignore the issue.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[aikido-pr-checks]

🟡 Medium - Delegated and scheduled executor wrappers reopen agent_api.jar on every task submission

Both bootstrap-safe executor wrappers now allocate a fresh URLClassLoader, load ContextPropagation, reflect the wrap(...) method, and close the loader for every submit/execute or schedule call. These methods are on the hot path for common asynchronous work, so the change adds repeated JAR parsing and reflective lookup overhead to every task dispatch instead of amortizing it once per JVM. Under request-driven executor usage this can materially reduce throughput and increase allocation pressure for the very async workloads this feature targets.

Show fix

Cache the reflected ContextPropagation class and wrap methods across calls instead of constructing a new URLClassLoader per task. If bootstrap isolation prevents direct helper references, initialize the reflective bridge lazily once in bootstrap-safe code and reuse the cached Method/MethodHandle objects for all subsequent submissions and schedules.

_{More info - Reply on this comment to give feedback or ignore the issue.}