[dajiaohuang]

Problem

MemoryPackOutputFormatter always writes the one-byte object-null header when context.Object is null, even when MVC supplies a concrete declared type. Null strings, arrays, lists and dictionaries use a four-byte null collection header in MemoryPack, so a client deserializing the response as the declared type cannot read this output.

This affects the documented MVC setup that inserts the MemoryPack formatter first: its CanWriteResult accepts the response before the normal no-content formatter handles nulls.

Change

When a usable declared type is available, send null values through the same typed serializer path as non-null values. Preserve the existing one-byte null output when the type is absent or only object.

Regression tests exercise the public MVC output formatter context with null string/array/list/dictionary values, compare its output to the public serializer, and round-trip the corrected output. Generated-class null and absent/object declared types cover compatibility.

Validation

• Four string/collection cases fail on main f96ba3054f14e528b5f75eba4ff02de0b71fa64a: output is FF instead of FF FF FF FF.
• The expanded seven-case MVC test set passes on this branch.
• Release solution build and pack pass (existing warnings remain).
• Windows x64, .NET 8 runtime / .NET SDK 10.0.100. No live HTTP server, Unity/IL2CPP or NativeAOT runtime checks were run.