[Fix] Support AOT for @Bean ReferenceBean

[Drifter-yh]

What is the purpose of the change?

Fixes #16145.

This PR fixes AOT support for Java-config @Bean methods annotated with @DubboReference and returning ReferenceBean<T>.

There were two related issues in this path:

1. The Java-config ReferenceBean metadata, including interfaceClass, interfaceName, and reference properties, was stored as BeanDefinition attributes, while the generated-artifact path restores this metadata from property values. As a result, the interface metadata and referencePropsJson were missing in AOT mode.

2. ReferenceAnnotationWithAotBeanPostProcessor.processAheadOfTime() only generated AOT contributions for field/method injection. A ReferenceBean<T> created by an annotated @Bean factory method therefore did not register the required proxy, reflection, and serialization runtime hints.

This change:

• persists the Java-config ReferenceBean metadata required by generated artifacts;
• adds AOT contribution support for annotated @Bean ReferenceBean<T>;
• reuses the existing RuntimeHints registration logic;
• handles ReferenceBean<GenericService> with an explicitly configured service interface;
• adds focused regression tests for metadata persistence and RuntimeHints generation.

Thanks to @mattmok for the detailed Native Image investigation in #16145.

Verification

The following focused and related tests pass:

• ReferenceAnnotationWithAotBeanPostProcessorTest
• JavaConfigReferenceBeanTest
• ReferenceAnnotationBeanPostProcessorTest

The new tests verify:

• interfaceClass, interfaceName, and referencePropsJson persistence;
• AOT contribution generation;
• JDK proxy RuntimeHints;
• reflection and serialization RuntimeHints;
• GenericService with an explicit service interface.

I did not run an end-to-end GraalVM native-image build locally. The regression tests exercise the Spring AOT metadata and RuntimeHints paths involved in the reported failure.

Checklist

• Make sure there is a GitHub_issue field for the change.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Make sure gitHub actions can pass. Why the workflow is failing and how to fix it?

[codecov-commenter]

Codecov Report

❌ Patch coverage is 12.28070% with 50 lines in your changes missing coverage. Please review.
✅ Project coverage is 36.89%. Comparing base (6054104) to head (23e8799).

Files with missing lines	Patch %	Lines
...n/ReferenceAnnotationWithAotBeanPostProcessor.java	0.00%	42 Missing ⚠️
...notation/ReferenceAnnotationBeanPostProcessor.java	46.66%	4 Missing and 4 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16428      +/-   ##
============================================
- Coverage     36.93%   36.89%   -0.04%     
+ Complexity    11752    11749       -3     
============================================
  Files          1952     1952              
  Lines         89249    89284      +35     
  Branches      13389    13397       +8     
============================================
- Hits          32961    32943      -18     
- Misses        51710    51752      +42     
- Partials       4578     4589      +11     

Flag	Coverage Δ
integration-tests-java21	32.07% <12.28%> (-0.01%)	⬇️
integration-tests-java8	32.20% <12.28%> (-0.02%)	⬇️
samples-tests-java21	32.12% <12.28%> (-0.06%)	⬇️
samples-tests-java8	29.80% <12.28%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Drifter-yh]

I investigated the failing Unit Test matrix.

The failure is unrelated to the AOT changes in this PR and is reproducible on the current 3.3 base as well.

AnnotationIsolationTest sets dubbo.metrics.protocol=disabled but does not clear the system property afterward. Since the tests share the same Surefire fork, SpringBootConfigPropsTest can subsequently observe disabled instead of the expected prometheus.

I reproduced the same order-dependent failure on both this PR branch and upstream/3.3. Running SpringBootConfigPropsTest in isolation passes.

I have intentionally not included the test-isolation cleanup in this PR to keep #16428 scoped to the AOT fix.