Libs: (bug) Debug.Assert in Number.FormatFloat fires for F/N/C/P formats with a large precision specifier #134101

Formatting a small floating-point value with a fixed-point format (F/N/C/P) and a precision at or above the type's round-trip digit count aborts the process on asserts-enabled (Checked/Debug) CoreLib builds. Release builds produce the correct string.

Minimal Repro

using System;
using System.Globalization;

internal static class P
{
    private static void Main()
    {
        double v = 3.141592653589793E-07;
        Console.WriteLine(v.ToString("F17", CultureInfo.InvariantCulture));
    }
}

Expected

0.00000031415926536

Actual

Process terminated.
Assertion failed.
((precision != -1) && (precision < TNumber.MaxRoundTripDigits)) || (TNumber.FloatToBits(value) == TNumber.FloatToBits(NumberToFloat<TNumber>(ref number)))
   at System.Number.FormatFloat[TNumber,TChar](ValueListBuilder`1& vlb, NumberBuffer& number, TNumber value, ReadOnlySpan`1 format, NumberFormatInfo info)
   at System.Number.FormatFloat[TNumber](TNumber value, String format, NumberFormatInfo info)
Aborted (core dumped)   # exit code 134

Notes

Root cause: for C/F/N/P, GetFloatingPointMaxDigitsAndPrecision sets isSignificantDigits == false and precision counts fractional digits, but the assert in FormatFloat (Number.Formatting.cs, ~L1016) compares it against TNumber.MaxRoundTripDigits, a significant-digit count. For values below ~0.1 the correctly-rounded result legitimately does not round-trip, so the assert fires. Gating it on isSignificantDigits would fix it.

Other confirmed variants: double F20/N17/C17/P15 with the same value, double F17 of 2^-20, float F9 of 0.00000095367431640625f, Half F5 of (Half)0.00006103515625; also via TryFormat (both char and byte) and string.Format. F16 does not assert, confirming the boundary. ~99% of doubles drawn from [0, 1e-3) hit it with F17. Introduced when the assert was generalized to TNumber.MaxRoundTripDigits in #102683.