seq: numerical precision issue causing difference from GNU output

This was found by the fuzzer in this job https://github.com/uutils/coreutils/actions/runs/12875524963/job/35897027858?pr=7181#step:7:4790. The logs for this test case started with

Running test ["seq", "18.499885215552325", "-0.0918587338370287", "-5068"]
Test Type: seq
Input: ["18.499885215552325", "-0.0918587338370287", "-5068"]
Rust stdout: 18.4998852155523250
# very long output...

You can narrow the test case down a bit to just

$ seq 18.499885215552325 -0.0918587338370287 -1006.7 |tail

Here is the diff between the output of GNU seq and that of uutils seq:

--- gnu	2025-01-20 16:20:55.686430468 -0500
+++ uutils	2025-01-20 16:20:58.638351255 -0500
@@ -2,9 +2,9 @@
 -1005.9087145349917374
 -1006.0005732688287661
 -1006.0924320026657948
--1006.1842907365028236
--1006.2761494703398523
--1006.3680082041768810
--1006.4598669380139097
+-1006.1842907365028235
+-1006.2761494703398522
+-1006.3680082041768809
+-1006.4598669380139096
 -1006.5517256718509383
 -1006.6435844056879670

There is a very small difference between some of the numbers due to some numerical precision issue. (The difference is in the last digit.)

Start by reproducing the narrowed seq command and comparing its output with GNU seq, especially the differing final digits shown in the diff. Trace the seq command's numeric formatting and stepping behavior to identify the precision discrepancy. Done means the reproduced values match GNU output for this case without introducing regressions.