Infer nullable non-handle ATS method returns in generated SDKs

### Is there an existing issue for this?

I have searched the existing issues.

### Describe the bug

`AtsCapabilityScanner` applies nullable-reference metadata to exported properties and parameters, but non-handle method return types are currently created from `method.ReturnType` without applying `NullabilityInfoContext` to the return parameter.

Nullable ATS method returns can therefore be generated as non-nullable APIs. This remains relevant for nullable primitives, enums, DTOs, arrays, and other non-handle return categories, including `Task` and `ValueTask` results.

Nullable handle returns are intentionally handled separately in #19880. That change covers `AsContainer()`, the existing `ModelExports.FindResourceByName()` gap, and `ResourceUrlsCallbackContext.GetEndpoint()` without broadening the generated shape of non-handle returns.

### Expected Behavior

The scanner should preserve nullable method-return metadata for direct non-handle returns and nested asynchronous results. Every generated SDK should represent absence idiomatically without changing unrelated type positions such as DTO properties.

Existing generated API compatibility must be assessed because correcting previously non-nullable signatures may require source changes in strongly typed consumers.

### Steps To Reproduce

1. Add or locate an ATS export returning a nullable non-handle type, directly or through `Task` / `ValueTask`.
2. Generate the Aspire SDKs.
3. Inspect the generated method signature.
4. Observe that the nullable return annotation is not consistently preserved.

### Aspire doctor output

N/A

### Anything else?

Split from the nullable-handle work in #19880 so the remaining scanner and generator behavior can be designed and compatibility-reviewed independently.

Start by tracing AtsCapabilityScanner's handling of non-handle method return types and compare generated signatures for direct nullable returns with Task and ValueTask results. Done means nullable return metadata is preserved in generated SDKs, unrelated type positions remain unchanged, and compatibility impact for existing consumers is assessed.

Written by the indexing model from the issue text.