Fix Linux crash loading recursive Nullable static-abstract value types

[Copilot]

This change addresses a Linux CoreCLR crash during prestub/JIT-triggered type loading of Nullable<T> when T is a recursively constrained value type using static abstract interface members. The failure came from System V struct classification assuming nested value-type metadata was always resolvable during approximate load.

• VM change

  • Teach managed-layout System V struct classification to treat temporarily unresolved nested value-type field metadata as a conservative fallback instead of asserting.
  • Reuse small helpers to:
    • resolve value-type field handles when available
    • compute field sizes without forcing the existing assert path
  • Result: recursive/partially loaded cases fall back to non-register passing rather than crashing.

• Regression coverage

  • Add a JIT regression covering the reported shape:
    • Nullable<UserId>
    • UserId as a readonly record struct
    • recursive generic interface constraint
    • static abstract interface members
  • Wire the test into Regression_o_2.

• Scenario covered

  class MyNullableUser
  {
      public UserId? UserId { get; set; }
  }
  
  public interface IEntityId<TSelf> : IEntityId
      where TSelf : IEntityId<TSelf>
  {
      EntityIdValue<TSelf> Value { get; }
      static abstract int MaxValue { get; }
  }
  
  public readonly record struct UserId(EntityIdValue<UserId> Value) : IEntityId<UserId>;

[dotnet-policy-service]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[davidwrighton]

@copilot, returning false from HasImpliedRepeatedFields or ClassifyEightBytesWithManagedLayout is not a conservative approach, it is incorrect. We need to find a suitable TypeHandle for running the logic, not giving up.