Pow with an integer exponent (and Exp) truncates the result to 1 significant digit: 1.234^2 == 2 #103

What's wrong

SignificantNumber.Pow (SignificantNumber/SignificantNumber.cs, ~line 579) sets the result precision with LowestSignificantDigits(this, power). An integer exponent such as 2 or 3 has 1 significant digit, and only -1, 0 and 1 are treated as exact, so the result is rounded to 1 significant digit. Exp has the same problem (~line 602).

This is separate from #101, which covers the lost sign of a negative base. The precision loss happens for positive bases too.

Reproduced against the current main build.

Why it matters

x.Pow(2) and x * x should agree, but they differ by up to an order of magnitude in reported precision. Any formula using squares or cubes (areas, volumes, kinetic energy, variance) silently collapses to one significant digit, which defeats the purpose of a significant-figures type.

Suggested fix

• Treat an integer exponent as exact, like the counting numbers in a multiplication. The result should keep the base's significant digits, which matches the behaviour of repeated multiplication.
• Apply the same rule to Exp: its precision should come from the exponent's value, not collapse to 1 digit for an integer input.
• Ideally, compute integer powers by repeated multiplication (or BigInteger) rather than Exp(Log(|x|) * p). That also keeps the sign, which would let this land together with the Pow returns a positive result for a negative base: (-2)^3 == 8, (-1)^3 == 1 #101 fix.

Acceptance criteria

• 1.234.Pow(2) == 1.234 * 1.234.
• Exp(2) returns more than 1 significant digit.
• Tests for integer exponents on non-trivial bases.