Potential unbounded allocation in SizeOfField for ELEMENT_TYPE_ARRAY metadata signatures

### Description ###

While reviewing ILDasm metadata processing code, I noticed a potential issue in SizeOfField when handling ELEMENT_TYPE_ARRAY signatures.

https://github.com/dotnet/runtime/blob/98bfa17c9f3910eec30099b7ac140d8a09df6227/src/coreclr/ildasm/dasm_sz.cpp#L182-L188

`new (nothrow)` is implemented as follows and returns nullptr when memory is low.:

https://github.com/dotnet/runtime/blob/98bfa17c9f3910eec30099b7ac140d8a09df6227/src/coreclr/nativeaot/Bootstrap/stdcppshim.cpp#L13-L16

If new (nothrow) fails due to insufficient memory, lowerBounds becomes nullptr, the subsequent operations (&lowerBounds[rank] and memset) would dereference nullptr, causing a crash

### Additional context ###
The .NET Runtime codebase typically includes null checks after new (nothrow) (e.g., `ASSERTE_ALL_BUILDS(result != NULL) pattern`). This appears to be an exception to that practice.

### Question ###
Could you please take a look? Is this a genuine issue, or am I missing some context where allocation failure is handled differently here (e.g., rank is guaranteed to be small, or nothrow behavior is overridden)?

Thank you!

Found by Linux Verification Center (linuxtesting.org) with SVACE.