Pow and Exp never return more than 15 significant digits because they compute in double, though PreciseNumber now provides exact Exp/Pow #137

What's wrong

Pow (SignificantNumber/SignificantNumber.cs:592-633) and Exp (:670-697) take a double path for every non-integer power and for integer powers above MaxExactIntegerPower (1024):

• PowByLogarithm (:645-662) computes Math.Exp(Math.Log(|x|) * p)
• Exp computes Math.Exp(power.To<double>())
• CapToExponentPrecision (:707-714) then caps the result at DoubleSignificantDigits (15) minus the exponent magnitude (the Pow and Exp report 15–17 significant digits when only 12–13 are correct for large |power·ln x| #113 fix)

So the documented contract, "rounded to the fewest significant digits of the two", is in practice "at most 15 digits", however precise both operands are.

The referenced ktsu.PreciseNumber (2.6.x, Directory.Packages.props) has implemented IExponentialFunctions/IPowerFunctions since v2.4.0 (ktsu-dev/PreciseNumber#81). PreciseNumber.Exp(x, significantDigits) and PreciseNumber.Pow(x, y) (PreciseNumber.Exponentials.cs) compute to arbitrary width without going through double.

Failure scenario

Scratch MSTest on .NET 10 at f3c593d:

x = 0.12345678901234567891                     (20 significant digits; E has 150)
SignificantNumber.Exp(x)      = 1.1314011145262        (15 digits; trailing 0 trimmed)
PreciseNumber.Exp(x, 20)      = 1.1314011145262015187

b = 1.1234567890123456789, p = 2.5000000000000000001  (both 20 digits)
b.Pow(p)                      = 1.33779920191736       (15 digits)
PreciseNumber.Pow(b, p) @ 20  = 1.3377992019173604607

The same double pipeline is also the root cause of #116 (a base near 1 is wrong from the 3rd digit) and #117 ((-1).Pow(2E308) throws). #116 proposes double.LogP1 plus a further digit cap; this issue proposes removing the double dependency instead, which would fix all three.

Suggested fix

• Compute the non-exact paths of Pow and Exp with PreciseNumber.Pow/PreciseNumber.Exp at the target significant digits plus a few guard digits, then ReduceSignificance to the target.
• Drop CapToExponentPrecision, FromLog10OfMagnitude and Log10OfMagnitude where no longer needed.
• Keep the exact integer-power path for |n| ≤ 1024.

Acceptance criteria

• Exp(0.12345678901234567891) has 20 significant digits, all matching the reference above.
• 1.1234567890123456789.Pow(2.5000000000000000001) returns 20 correct digits.
• The cases in Pow of a base near 1 is wrong from the 3rd digit but reports 15 significant digits: 1.00000000000001^1E14 = 2.71611… (true 2.71828…), and x^1025 == x^1024 #116 and (-1).Pow(2E308) throws OverflowException "The result is too small to represent." instead of returning 1 #117 pass, or those issues are closed by this change.
• Results outside double's range (Exp(710), 10.Pow(2000.5)) still work (see Pow and Exp throw for results beyond double range and return exact 0 for tiny ones (10.Pow(2000), Exp(710), 2.Pow(-1100)) #106).