Fix 0/0 = NaN in the rise/set parabola fit

[chaunceygardiner]

Fixes #1114. The full analysis is in my comment on that issue; the short version:

By the time _find() reaches its final parabola refinement, the Newton iteration has sometimes already converged so tightly that the last two sample times are numerically adjacent instants, and the recomputed altitude offset from the horizon is bit-identical at both. When that offset happens to land on exactly 0.0, _q() divides 0/0: the numerator -2*c is -0.0 because c = y0 = 0.0, and with y0 == y1 the sign is +1, so the denominator b + sqrt(b*b) is 0.0 whenever b < 0. The resulting NaN survives np.clip() and is returned as the event time, while is_above_horizon stays True — NaN comparisons are False — so callers cannot filter the bad event and crash later in utc_iso()/utc_datetime() with ValueError: cannot convert float NaN to integer.

When c is zero, x = 0 is exactly a root of the quadratic — the curve passes through zero at the first sample point, which is where the iteration converged — so _q() now returns it directly. The errstate guard keeps NumPy quiet while the discarded quotient is computed.

The trigger is last-ULP rounding of the whole trig pipeline, which is why the failing (date, latitude, body) tuples in the issue thread differ across platforms and NumPy builds. The new test therefore skips the ephemeris entirely and feeds _intersection() the exact operands captured from a failing case (a Mars setting at 52.0°N on 2029-11-04, on Linux/aarch64 with NumPy 2.4.1): it computes NaN before this change and 0.0 after.

With the fix, both deterministic cases from the thread return times that agree with an independent find_discrete search over risings_and_settings on the same day:

2029-11-04 mars             52.0°N   set 18:45:31Z   (find_discrete: 18:45:31Z)
2029-10-14 saturn           68.4°N   set 11:15:42Z   (find_discrete: 11:15:42Z)

Test suite: the failing-test set under assay --batch skyfield.tests is identical before and after the change (the failures on my machine are pre-existing NumPy 2.5 deprecation warnings escalated by PYTHONWARNINGS=error, unrelated to this fix), and the new test passes. pyflakes is clean.