Log(5, -2) throws ArgumentOutOfRangeException naming parameter x with value -2: an invalid base is reported as an invalid argument #196

What's wrong

Log(x, newBase) and Log(x, newBase, significantDigits) don't check the base themselves. They pass it to the single-argument Log(newBase, working), whose domain-error guard names x. So a bad base is reported as a bad x, with the base's value as ActualValue. Before it throws, the call also works out Log(x) to full working precision, for nothing.

Repro (HEAD f690afc)

PreciseNumber.Log(5, -2);  // ArgumentOutOfRangeException: ParamName = "x", ActualValue = -2
                           // "A logarithm is only defined for a positive value. (Parameter 'x')"
PreciseNumber.Log(5, 0);   // ParamName = "x", ActualValue = 0
PreciseNumber.Log(-5, 2);  // ParamName = "x", ActualValue = -5   (correct, for comparison)

Expected: ParamName = "newBase", since x (5) is valid.

Why it matters

The message says x is wrong when it isn't. Callers, logging, or argument-validation code that read ParamName blame the wrong argument.

Root cause

• PreciseNumber/PreciseNumber.Exponentials.cs ~L192-197 calls DivideApproximation(Log(x, working), Log(newBase, working), …).
• The guard in Log(PreciseNumber, int) (~L134-137) throws new ArgumentOutOfRangeException(nameof(x), x, …).

Suggested fix / acceptance criteria

• In Log(x, newBase, significantDigits), check newBase <= 0 before computing either logarithm, and throw ArgumentOutOfRangeException(nameof(newBase), newBase, …).
• Tests assert ParamName == "newBase" for Log(5, -2) and Log(5, 0).
• The documented DivideByZeroException for base 1 stays as it is.

Near-duplicates checked: #147 and #183 (log-in-a-base rounding), #190 / #192 (domain-error messages at large exponents).