[release/9.0-staging] Fix TensorPrimitives.MultiplyAddEstimate for integers

[github-actions]

Backport of #113047 to release/9.0-staging

/cc @stephentoub

Customer Impact

• Customer reported
• Found internally

TensorPrimitives.MultiplyAddEstimate produces the wrong answers when used with integer types, e.g.

using System.Numerics.Tensors;

ReadOnlySpan<long> x = [1, 2, 3];
ReadOnlySpan<long> y = [4, 5, 6];
ReadOnlySpan<long> addend = [7, 8, 9];
long[] destination = new long[3];
TensorPrimitives.MultiplyAddEstimate(x, y, addend, destination);

Console.WriteLine(string.Join(", ", destination));

That should print 11, 18, 27 (i.e. 1*4 + 7, 2*5 + 8, 3*6 + 9), but it prints 7, 8, 9.

Customers using this method will get the wrong numerical results.

Regression

• Yes
• No

Testing

Added new tests to the System.Numerics.Tensors test suite. Previously there were only tests for floating-point types, and this issue was specific to integer types.

Risk

Low. It's a very isolated change specifically for the MultiplyAddEstimate implementation, where previously there was a structure like:

if (typeof(T) == typeof(double)) { ... /* optimize for double */ }
else { ... /* optimize for float, but oops if T is an integer */ }

and this fixes it to be:

if (typeof(T) == typeof(double)) { ... /* optimize for double */ }
else if (typeof(T) == typeof(float)) { ... /* optimize for float */ }
else { ... /* handle generically */ { ... }

There's no reasonable way someone could have taken a dependency on the previous behavior. This method was also only introduced in .NET 9.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

[stephentoub]

cc: @jeffhandley, @artl93