sig.Equals(precise) returns false for equal values while sig == precise, precise.Equals(sig) and CompareTo all say they're equal #143

What's wrong

SignificantNumber is a readonly record struct (SignificantNumber/SignificantNumber.cs:28) with no Equals(PreciseNumber) overload. So sig.Equals(precise) binds to the synthesized Equals(object), which boxes the PreciseNumber, fails the is SignificantNumber type check, and returns false.

Every other way of comparing the same pair treats it as equal:

• the mixed == operators (SignificantNumber.cs:456-466)
• CompareTo(object)
• precise.Equals(sig), which binds to PreciseNumber.Equals(PreciseNumber) through the implicit conversion

Reproduction (HEAD 289cc6f)

var s = SignificantNumber.Parse("1.5");
var p = PreciseNumber.Parse("1.5");
s == p                  // True
p.Equals(s)             // True
s.Equals(p)             // False
((object)s).Equals(p)   // False
s.CompareTo((object)p)  // 0

This is not a regression: 1.4.40 gives the same results.

Why it matters

• measured.Equals(expectedPrecise) is false while measured == expectedPrecise is true, so an assertion, List.Contains/IndexOf, or LINQ Contains that uses Equals silently misses an equal value.
• Equals is not symmetric, which breaks the Equals contract.
• The migration guide says "Compare values with == or Equals", but which of the two you pick changes the answer.

Suggested fix / acceptance criteria

• Add public bool Equals(PreciseNumber other) => Value.Equals(other);, plus IEquatable<PreciseNumber> if desired, so that s.Equals(p) == p.Equals(s) == (s == p).
• Document the remaining case: Equals(object) with a boxed PreciseNumber stays false, because the record struct's Equals(object) can't be customised, even though CompareTo(object) returns 0 for it.
• Add tests that cover both argument orders, plus the boxed case, for equal and unequal values.