refactor(core): one PrintExposureTime instead of sixteen

[swackhamer]

Image::ExifTool::Exif::PrintExposureTime had been ported into sixteen
separate modules. Four of the copies printed a different string than ExifTool
for the same number of seconds. Every copy shipped with its own unit tests
asserting its own output, so all sixteen were green.

# Exif.pm:5606
sub PrintExposureTime($)
{
    my $secs = shift;
    return $secs unless Image::ExifTool::IsFloat($secs);
    if ($secs < 0.25001 and $secs > 0) {
        return sprintf("1/%d",int(0.5 + 1/$secs));
    }
    $_ = sprintf("%.1f",$secs);
    s/\.0$//;
    return $_;
}

The four divergences

All of them are in the branch above 0.25 s; the reciprocal branch was right
everywhere.

1. sony/binary.rs never rounded to one decimal

It rendered the slow branch with print_float — ten decimal places — instead
of sprintf("%.1f"). Two tables reach it, both of which derive seconds from an
APEX exponent, so the reachable values are irrational and the full quotient
came out:

tag	ValueConv	raw values wrong	example
Sony:ShutterSpeedSetting	2**(6-$val/8)	56 / 256	ExifTool 58.7, oxidex 58.6882587651
Minolta:ShutterSpeed	2**((48-$val)/8)	56 / 256	ExifTool 11.3, oxidex 11.3137084990

(minolta_tables.rs:10 imported print_exposure_time from sony::binary, so
the Minolta tables inherited the Sony bug.)

2/3/4. pdf/mod.rs, sigma.rs, sony/binary_data.rs dropped s/\.0$//

They replaced the trailing-zero regex with an secs == secs.trunc() test taken
before formatting. That is a different question. 29.96 is not an integer, but
%.1f rounds it to "30.0" — ExifTool's regex then strips the .0 and prints
30, while these three printed 30.0.

Over [0.25 s, 40 s] sampled at 1e-4 that is 39,449 of 375,000 inputs.
Among 1/8-stop APEX shutter speeds it is 2^4.25 (19.03 s → 19 vs 19.0) and
2^6.375 (83.00 s → 83 vs 83.0).

Reached by Sigma:ExposureTime (0x0032 and the microsecond string at 0x0033),
the PDF/XMP APEX ShutterSpeedValue path, and Sony's Pc::ExposureTimeOrBulb.

5. composite/compute.rs open-coded the rounding

(v*10.0+0.5).floor()/10.0 is round-half-up; %.1f is round-half-to-even on
the exact binary value. Composite:ShutterSpeed of 0.35 s printed 0.4 where
ExifTool prints 0.3; 2.25 s printed 2.3 where ExifTool prints 2.2.
198 of 375,000 inputs over the same range.

What this PR does

Adds core::formatters::exif_print_conv with the one port plus the &str
wrapper the two APP12 text segments need for Exif.pm:5609's
return $secs unless IsFloat, and deletes all sixteen local copies —
including the eleven that were already equivalent, because a helper that
exists sixteen times is a helper that will diverge again.

18 files changed, 162 insertions(+), 260 deletions(-)

Verification

• Ground truth. All 22 assertions in the new module were checked by calling
  Image::ExifTool::Exif::PrintExposureTime from ExifTool 13.55 directly, not
  by reading the Perl. Both divergence counts above were produced the same way.

• No regressions. oxidex -a -e run under fd8a7322 and under this branch
  over all 4,240 files of the combined-samples corpus, diffed as matched
  sets of Group:Name: Value lines rather than by totals:

  corpus files compared      : 4240
  total tag lines emitted    : 529212   (files emitting nothing: 4)
  files with any diff        : 4221     <- all but one are File:FileAccessDate
  files with a real diff     : 1
  

  File:FileAccessDate moves on every file because the harness reads each one
  twice; it is atime churn, not output. The single real change is
  Samsung/SamsungDigimax340.jpg, Composite:ShutterSpeed 7.3 -> 7.2 —
  the composite/compute.rs rounding fix above, landing on the value %.1f
  produces for 7.25.

  That tag is still wrong against ExifTool (1/152), for an unrelated and
  pre-existing reason this diff surfaced: oxidex feeds the composite the raw
  stored APEX ShutterSpeedValue (7.25) instead of its ValueConv'd seconds
  (Exif.pm:2322, 2**(-$val)), which it does apply correctly when emitting
  ExifIFD:ShutterSpeedValue. Composite:Aperture on the same file has the
  same defect (4.5 vs 4.7). Filed separately; parity for those tags was a
  miss before this PR and is a miss after it.

  Correction: an earlier revision of this description reported
  files whose tag SET differs: 0. That run passed -G1, which oxidex does not
  accept, so both binaries emitted nothing and the comparison was vacuous. The
  numbers above are from the re-run, which carries an emitted-line count
  precisely so an all-empty run cannot pass again.

• cargo fmt --all, cargo clippy --workspace clean, cargo test --workspace
  all green. CI on the merge head: Build & Test, Lint & Audit, Verify Generated
  Tables, CodeQL and docs all success.

Note that the corpus contains no file that trips any of the four bugs — every
Sony/Minolta shutter setting in it is in the reciprocal branch, and no
ExposureTime lands on the rounding boundary. That is precisely why sixteen
copies could drift for this long: the guard has to be a unit test pinned to
ExifTool's own function, which is what the new module carries.

Follow-ups this pass did not take

Sized, with the divergence already measured:

1. perl_number × 6 ({:.6} truncation). canon.rs and
   canon/camera_info.rs hold byte-identical format!("{:.6}", v) copies of
   Perl's %.15g; measured against Perl over 3,263 realistic values they are
   wrong on 1,028. custom_functions2.rs uses an (-6..15) exponent
   bucket where C's %g uses -4: wrong on 315. h264.rs uses Rust's
   {} (shortest round-trip, 17 digits): wrong on 1,015, though its single
   call site's 128-value domain happens to agree. table_ifd.rs::fmt_g15 takes
   log10().floor() before rounding and so mis-buckets values that round
   across a power of ten. The canonical
   core::formatters::numeric_precision::perl_number is wrong on 1 — the
   Perl IV-integer case at ≥1e15, unreachable for metadata. ~5 files.
2. The parity harness measures a formatter the library never ships.
   src/bin/tag-comparison/extraction/oxidex_extractor.rs:19 imports
   format_with_unit and needs_unit_suffix from core::value_formatter,
   whose format_with_unit is a naive format!("{} mm", value). The library
   uses core::formatters::unit_suffixes, which applies Exif.pm:2401's
   sprintf("%.1f mm",$val). So EXIF:FocalLength is 50.0 mm in the product
   and 50 mm in the measurement. One-line import change, but it moves the
   reported coverage number, so it wants its own PR.
3. print_f_number × 4 — composite/compute.rs:400 applies {:.1} when
   $val <= 0, where Exif.pm:5620's and $val > 0 guard returns the value
   untouched: 0 prints as 0.0.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com