fix: Consumer-facing API lacks nullability annotations, defeating Kotlin null-safety

[obabichevjb]

What is the purpose of the change?

Fixes #16487

Dubbo's most-travelled consumer entry points carry no nullability annotation, so Kotlin models
their returns as platform types and relaxes null-checking at that boundary. This compiles today
with zero warnings, and fails at runtime:

This PR annotates five methods so the compiler rejects that instead:

Method	Annotation	Basis
Result.getValue()	@Nullable	Javadoc already states "if no result return null"
Result.getException()	@Nullable	Javadoc already states "if no exception return null"
RpcContext.getAttachment(String)	@Nullable	returns null for an absent key
RpcContextAttachment.getAttachment(String)	@Nullable	returns null for an absent key
ReferenceConfig.get() / get(boolean)	@Nonnull	never returns null — throws, or returns a proxy

The four @Nullable annotations only make machine-readable a contract the Javadoc already states
in prose. ReferenceConfig.get() is the inverse case: a platform type that is in fact never null,
so Kotlin users lose type information for no reason at the most-used call site in the API.

Annotating with Dubbo's own annotation would have no effect on Kotlin callers. Kotlin honours a
fixed set of nullability annotations, and common.lang.Nullable carries no JSR-305
meta-annotations.

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

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 58.93%. Comparing base (a87b134) to head (56c4f0c).

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16488      +/-   ##
============================================
- Coverage     60.92%   58.93%   -2.00%     
+ Complexity    11764       15   -11749     
============================================
  Files          1953     1953              
  Lines         89275    89275              
  Branches      13474    13474              
============================================
- Hits          54394    52614    -1780     
- Misses        29301    30964    +1663     
- Partials       5580     5697     +117     

Flag	Coverage Δ
integration-tests-java21	?
integration-tests-java8	?
samples-tests-java21	?
samples-tests-java8	?
unit-tests-java11	59.14% <ø> (-0.03%)	⬇️
unit-tests-java17	58.66% <ø> (+0.02%)	⬆️
unit-tests-java21	58.65% <ø> (-0.01%)	⬇️
unit-tests-java25	58.60% <ø> (-0.03%)	⬇️
unit-tests-java8	59.16% <ø> (-0.05%)	⬇️

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.

[LI123456mo]

Good fix, I have no idea about that failing or skipped test @RainYuY @zrlw @oxsean or any other mantainer to look at this

LGTM.