seq: fix -w padding for scientific notation with leading placeholder zero

[MadeNavaneeth]

Summary

Fixes seq -w padding width for scientific notation operands where the mantissa has a leading placeholder zero (e.g. 0.5e1, -.1e2).

When the mantissa starts with 0. (or -./.) and a positive exponent shifts the decimal point past that zero, the zero is no longer part of the integral representation. Previously, compute_num_digits kept the counted digit and added the exponent on top, inflating the integral-digit count by one.

Problem

For seq -w 0.5e1 0.5e1:

• Before: outputs 05 (padding width 2)
• After: outputs 5 (padding width 1, matching GNU)

For seq -w -.1e2 10 100:

• Before: outputs -010, 0000, ... 0100 (padding width 4)
• After: outputs -10, 000, ... 100 (padding width 3, matching GNU)

Fix

In compute_num_digits, after applying a positive exponent, check if the mantissa has a leading placeholder zero (0.xxx, .xxx, or -.xxx) and the fractional part contains a non-zero digit. If so, subtract 1 from the integral digit count, since the exponent shifts the decimal past the placeholder zero.

The check for non-zero fractional digits ensures we don't affect cases like 0.0e15 (where the zero is the actual value, not a placeholder).

Tests

• Updated test_num_integral_digits unit tests to reflect corrected counts
• Updated test_width_negative_scientific_notation integration test to match GNU behavior
• All 104 seq integration tests pass

Fixes #14153

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/cut/bounded-memory (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/date/date-locale-hour (fails in this run but passes in the 'main' branch)
Congrats! The gnu test tests/csplit/csplit-heap is now passing!
Congrats! The gnu test tests/seq/seq-epipe is now passing!