fix(java): run descriptor warm-up on Fory's compiler pool to fix thread context classloader

[stevenschlansker]

Why?

The Descriptor class uses ForkJoinPool.commonPool() which is global to the whole JVM.
When Fory is loaded by an isolated classloader other than the system loader, like a WAR, warmup tasks run with the wrong context classloader (TCCL) - the system loader or inherited, depending on JDK version.

What does this PR do?

• Warm-up now uses CodeGenerator.getCompilationService(), Fory's own pool. ForyJitCompilerThreadFactory sets each pool thread's TCCL to the loader that defines Fory, instead of inheriting the TCCL of the submitting thread. Fory already falls back to that loader when the TCCL is null.

• Remove shutdown hook for CodeGenerator thread pool: it retains Fory's classloader until exit, and the pool is daemon anyway.

• seMaxCompilationThreadPoolSize now rejects requested thread count < 1

• Native-image build time keeps the common pool, because the compiler service is a direct executor there. Pool size computed at native-image runtime instead of build time.

• TODO in the code is removed

Related issues

#3138 introduces the shutdown hook without much explanation. I do not want to delete a necessary feature, but shutdown hooks are JVM-global and should be used sparingly.

AI Contribution Checklist

• substantial_ai_assistance: yes
• scope: all
• affected_files_or_subsystems: java core
• ai_review: Opus 5.5 xhigh, with and without Fory review
• human_verification: line by line review of code and check test fails on master
• performance_verification: Basic performance regression test run, noted that CodeGenerator machinery moves earlier in initialization process
• provenance_license_confirmation: No third party code

Review artifacts inline:

Two Opus xhigh reviewers, one using the Fory review workflow and one independent, found no critical or high issue in commit 9668c2d. The change moves descriptor warm-up to Fory's compiler pool, pins the pool's context classloader, and removes its shutdown hook, and new tests cover each part.
The PR benchmark resolves the one medium finding: with synchronous JIT the first serialization is within noise, and steady-state serialization does not change. With async compilation, the first serialization is 1.1% to 1.7% slower once at startup, above the Fory 1% threshold, so the PR must cite the fix as justification. The remaining findings are low or nit, such as inherited pool-thread state and two owners for the build-time executor choice. I approve the change, provided the PR names the classloader fix as the reason to accept the async-compilation startup cost.

Signed off by Claude Opus 5.5 (claude-opus-5-5).

I worked through the low and nit findings and declined them: large increase of scope to fix small problems:

• Pool threads still inherit inheritable thread locals and thread group
• Pre-existing name conflict check due to use of short class name in CodegenContext cache
• Descriptor and Generator both have thread pool selection logic: the logic is correct and simple as is

Does this PR introduce any user-facing change?

• seMaxCompilationThreadPoolSize now rejects requested thread count < 1
• seMaxCompilationThreadPoolSize must now be set before Fory descriptors are read, otherwise it warns
• Slight change to initialization order: CodeGenerator hits static-init sooner
• Code generator pool initializes in some cases it did not before, like Android and native-image

No negative production impact anticipated.

Benchmark

I compared this branch with apache/main (33abafa) on JDK 25, using a generated graph of 400 classes with nested object, List, and Map fields. Each measurement ran in a fresh JVM, the two versions alternated in adjacent pairs, and I report the median of 20 rounds at -XX:ActiveProcessorCount=2 and 8. The first serialize with synchronous JIT changed by +0.2% at 2 CPUs and -0.1% at 8 CPUs, which is within noise.
The first serialize with async compilation, timed until both the common pool and the compiler pool were idle, was 1.7% (36 ms) slower at 2 CPUs and 1.1% (22 ms) slower at 8 CPUs. A cold descriptor build with no Fory instance was 5.7 ms (8%) slower at 2 CPUs and 10 ms (16%) slower at 8 CPUs, mostly because it now loads about 94 more classes for CodeGenerator and its executor, which a Fory instance that compiles loads anyway. With the compiler pool already created, that difference falls to 1.4 ms (2.6%, measured at 4 CPUs), and the change does not touch the steady-state serialization path.

Since this is a bugfix, I think a small startup cost is worth it.