Nullable warnings are not emitted consistently for generic component bindings and can be non-actionable due to generated code

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

Nullable reference type warnings are not consistently emitted when using generic Blazor components with `@bind`.

The presence or absence of warnings depends on how the generic type parameter is specified in Razor, even when the effective types are equivalent. Additionally, when warnings do appear, they originate from generated code and are not actionable in user code.

### Expected Behavior

Nullable analysis should behave consistently across all usages.

Since `value `is of type `string?`, binding it to a component parameter of type `T` should either:

- consistently produce a warning when nullability does not match, or
- consistently not produce a warning if the scenario is considered valid.

The behavior should not depend on whether `T` is inferred, explicitly specified as `string`, or explicitly specified as `string?`.

### Actual behavior
When T is inferred > no warning
When T="string" > no warning
When T="string?" > warning is emitted

The warning produced is:

> “The annotation for nullable reference types should only be used within a #nullable annotations context. Auto-generated code requires an explicit #nullable directive in the source.”

This warning originates from generated `.g.cs` code rather than user code.

### Steps To Reproduce

### Component
```
public partial class GenericTypeSample : ComponentBase
{
[Parameter] public T Value { get; set; } = default!;

[Parameter]
public EventCallback ValueChanged { get; set; }
}
```
### Usage
```
@* No warning *@

@* No warning *@

@* Warning is produced *@

@code {
private string? value = "Blazor";
}
```

### Exceptions (if any)

_No response_

### .NET Version

10.0.201

### Anything else?

### Key issue

The warning is not actionable:

- It is triggered by Razor-generated code
- Users cannot modify the generated `.g.cs` files
- It is not possible to enable nullable context within that generated code from user code

This aligns with the problem described in the previously closed issue:
[https://github.com/dotnet/razor/issues/7169](https://github.com/dotnet/razor/issues/7169)

Even though that issue was closed, the underlying limitation still applies:
**nullable annotations in generated Razor code can produce warnings that users cannot fix.**

### Limitations / Workarounds

The only ways to eliminate the warning are:

- removing the explicit generic type parameter (`T="string?"`) and relying on type inference, or
- removing the nullable annotation (`string?`) from the generic type argument

Both options suppress the warning rather than resolving the underlying issue.

### Additional context
- Nullable analysis is not consistently applied across Razor generic bindings
- Nullable context is not properly propagated into generated code
- Diagnostics originating from generated code are not reliably mapped to user code

### Impact

Developers may:

- miss important nullable warnings in some cases, and
- receive non-actionable warnings in other cases

This leads to inconsistent null-safety guarantees and reduced trust in compiler diagnostics for Blazor components.

### Environment
**.NET SDK:**
Version: 10.0.201
Commit: 4d3023de60
Workload version: 10.0.200-manifests.121cc9e6
MSBuild version: 18.3.0-release-26153-122+4d3023de6

The folloing attachment contains the above sample
[unfixablewarning.zip](https://github.com/user-attachments/files/26307127/unfixablewarning.zip)