[mono][wasm] Type loader aborts (object.c:8000) / false "Recursive type definition detected" on a struct with a static ValueTask<Self> field

### Description

On the Mono/WebAssembly runtime, loading `ValueTask` aborts when `T` is a value type that declares a **`static` field of type `ValueTask`** (i.e. `T` statically references `ValueTask`, whose instance layout contains a `T`). The runtime dies with a native assertion:

```
[MONO] * Assertion at /__w/1/s/src/runtime/src/mono/mono/metadata/object.c:8000, condition `' not met
```

In some (larger / Release) builds the same root cause surfaces instead as a managed exception:

```
System.TypeLoadException: Recursive type definition detected System.Threading.Tasks.ValueTask`1
```

The type is **not** genuinely recursive: a `static` field does not participate in a type's instance layout, and `T` here is a `readonly record struct` of `Size = 1`, so `ValueTask` has a well-defined finite layout. **CoreCLR loads and runs the identical IL without any error.** This is the same class of false positive as #85821 ("Mono incorrectly throws a TypeLoadException for a recursive type definition"), which was fixed for the `T[]` array path by #115278 ("[mono][metadata] Defer class init for T when initializing `T[]`"). That fix does not cover this case: a **static field whose type is a generic struct that transitively references the declaring type**.

The offending type (a MediatR/MediatorLite-style `Unit`):

```csharp
[StructLayout(LayoutKind.Sequential, Size = 1)]
public readonly record struct Unit : IEquatable, IComparable
{
public static readonly Unit Value = default;

// Get-only auto-property with initializer => static ValueTask backing field inside Unit:
// static ValueTask k__BackingField
// -> Unit statically references ValueTask, whose _result field is a Unit.
public static ValueTask CompletedTask { get; } = ValueTask.FromResult(Value);
}
```

The abort is a **native runtime assertion, not a catchable managed exception** — a surrounding `try/catch` does not catch it, so a Blazor WebAssembly app that loads this type simply dies. This is not academic: `Unit`/`ValueTask` result types are used by MediatR-style mediators (this was found via MediatorLite v2, whose source-generated mediator returns `ValueTask`), so any request dispatched through such a mediator aborts a Blazor WASM client at startup.

**The failure is load-order dependent.** If `ValueTask` is first loaded via a benign path (e.g. touching `Unit.CompletedTask` directly) *before* the path that trips the detector, the type loads successfully and the crash is masked for the rest of the process. The minimal repro therefore loads `ValueTask` first via the mediator dispatch and does not touch `Unit.CompletedTask` beforehand.

### Reproduction Steps

Minimal, dependency-free repro (two projects sharing the same types): **https://github.com/SolemnDucc/mono-wasm-recursive-typeload-repro**

1. `dotnet run --project BlazorWasm` and open the URL in a Chromium/Chrome browser.
- Hand-written `ValueTask` probes (direct, `async`, and the `Unsafe.As,ValueTask>` reinterpret) render `OK`.
- The first dispatch that loads `ValueTask` aborts the runtime; the page freezes and the console shows the `object.c:8000` assertion.
2. `dotnet run --project CoreClr` runs the **same** types on CoreCLR and prints every dispatch (and a direct `Unit.CompletedTask` load) as `OK`, ending `ALL OK on CoreCLR (.NET 10.x)`.

- Likely related to the recursion detection in `mono/metadata/object.c` (the same area addressed by #85821 / #115278). The `T[]`-path fix deferred class init for `T` when initializing `T[]`; the analogous deferral seems to be missing when a `static` field's type is a generic struct instantiation that closes back over the declaring type.
- Beyond the false positive, a type loader aborting on a **native assertion** for valid managed IL (that CoreCLR accepts) is itself worth addressing — even the "correct" diagnosis should be a managed `TypeLoadException`, not an uncatchable runtime abort.