Empty multidimensional arrays can fail deserialization when a later dimension is zero #11391

Reproduction

Confirmed on unmodified dotnet/orleans main 9bb744ad5fe9bd0a512052f1b11c1d6b6f7a44f1, using Orleans.Serialization, Version=10.0.0.0 and .NET 10.0.12. This reproduces with a built-in element type and a typed root:

using var services = new ServiceCollection().AddSerializer().BuildServiceProvider();
var serializer = services.GetRequiredService<Serializer>();
var original = new int[2, 0];
var payload = serializer.SerializeToArray(original);
var result = serializer.Deserialize<int[,]>(payload);

Expected: an empty rank-two array with dimensions [2, 0].

Actual:

System.IndexOutOfRangeException:
Declared dimensions [2, 0] require more elements than the remaining length of the input, 1.

The stack enters MultiDimensionalArrayCodec<T>.EnsureSufficientData (src/Orleans.Serialization/Codecs/MultiDimensionalArrayCodec.cs, lines 163–182). It checks the partial dimension product against remaining bytes before reaching the later zero dimension. The complete product is zero, so the writer correctly emits no elements. The supported [0, 2] shape avoids the early check.

Context

Found while capturing backward-compatibility fixtures for a separate compound-alias array type-name resolution fix. The standalone int[2,0] reproduction above was run with RuntimeTypeNameRewriter.cs exactly matching main (blob 8a7e9d2ef03fbbe0cdda27e322eb2ad7cb6dc095). This codec failure is independent of compound aliases and is being tracked separately from that focused PR.

Searched existing issues and PRs for empty/multidimensional arrays, declared dimensions, zero dimensions, and EnsureSufficientData. Closed #5918 concerns Orleans 2.4.1's older BinaryTokenStreamReader and a different exception; no matching open report or recent fixing PR was found.