fix(java): Correct the async meta-shared layer bootstrap in ObjectStreamSerializer

[mandrean]

Why?

This is a follow-up to #3342 and #3344 for the .withAsyncCompilation(true) path.

While investigating a downstream flaky serialization failure on the same general ObjectStreamSerializer/customized JDK serialization area, I found a separate issue in the async meta-shared layer JIT path. ObjectStreamSerializer can trigger that path for classes such as TreeSet/TreeMap subclasses, and the generated layer serializer could be bootstrapped through the wrong path, causing failures such as NoSuchMethodException and ClassCastException.

What does this PR do?

This PR fixes async meta-shared layer bootstrap for ObjectStreamSerializer by:

• caching layer context for generated meta-shared layer codec classes
• using that cached context to initialize the interpreter MetaSharedLayerSerializer delegate
• removing the broken second-stage async swap for layer serializers
• adding regression coverage for async-compatible ObjectStreamSerializer cases with nested TreeSet/TreeMap subclasses and customized JDK serialization

Closes #3515.

Related issues

• Follow-up to fix(java): Deserialize nested HashMap subclasses #3342
• Follow-up to fix(java): support TreeSet/TreeMap subclasses without Comparator constructor in SortedSet/SortedMapSerializer #3344
• Closes [Java] ObjectStreamSerializer async meta-shared layer JIT fails for TreeSet/TreeMap subclasses #3515

AI Contribution Checklist

• Substantial AI assistance was used in this PR: yes
• If yes, I included a completed AI Contribution Checklist in this PR description and the required AI Usage Disclosure.
• If yes, I can explain and defend all important changes without AI help.
• If yes, I reviewed AI-assisted code changes line by line before submission.
• If yes, I ran adequate human verification and recorded evidence (checks run locally or in CI, pass/fail summary, and confirmation I reviewed results).
• If yes, I added/updated tests and specs where required.
• If yes, I validated protocol/performance impacts with evidence when applicable.
• If yes, I verified licensing and provenance compliance.

AI Usage Disclosure

• substantial_ai_assistance: yes
• scope: refactor suggestions, tests
• affected_files_or_subsystems: java/fory-core meta-shared layer codec bootstrap, ObjectStreamSerializer async layer JIT path, ObjectStreamSerializerTest
• human_verification: reviewed changes line by line; ran mvn -pl fory-core -am -Dtest=ObjectStreamSerializerTest,JITContextTest -Dsurefire.failIfNoSpecifiedTests=false test locally and reviewed the passing results; also validated the downstream reproducer with the patched local Fory build and reviewed the passing targeted test result (which fails without the fixes here)
• performance_verification: exploratory local benchmark checks did not show a consistent overall regression in the general compatible/meta-shared proxy suite; no formal performance claim is made in this PR
• provenance_license_confirmation: Apache-2.0-compatible provenance confirmed; no incompatible third-party code introduced

Does this PR introduce any user-facing change?

• Does this PR introduce any public API change?
• Does this PR introduce any binary protocol compatibility change?

Benchmark

No formal benchmark claim is included in this PR.

This PR is a correctness fix for async layer serializer bootstrap. I did run exploratory local checks against the existing general compatible/meta-shared proxy benchmarks and did not see a consistent overall regression.

I also locally created a focused JMH benchmark intended to exercise the exact ObjectStreamSerializer async layer JIT hot path touched by this change. However, on the baseline code that benchmark reproduces the bug fixed by this PR and fails during setup with the same NoSuchMethodException / ClassCastException async layer bootstrap errors, so it was not possible to establish a reliable before-fix baseline from that targeted benchmark.