fix(cli): parse -TAG=VALUE into the tag's declared type

[swackhamer]

The defect

The CLI built every -TAG=VALUE as a String, so no Integer, Rational or DateTime tag could be
set from the command line on any format, JPEG included:

$ oxidex -ExifIFD:ISO=800 photo.jpg
Error: Invalid value for tag 'ExifIFD:ISO': Type mismatch: expected Integer but got String

Two entry points, one root cause. src/main.rs:146 wrapped every value as TagValue::String; the
batch path (cli::batch_processor::parse_tag_value) guessed a type from the value's shape, so
-IFD0:Artist=800 became Integer(800) and was rejected the other way round. The write path
validates against the type the tag declares, which the registry already carries.

Pre-existing and independent of #358 — verified against origin/main (92e4eaf4).

The fix

src/cli/value_parser.rs resolves the declared type from get_tag_descriptor and parses the
argument into it before it reaches the writer. Both entry points call it.

ExifTool's accepted input forms (established from source, not guessed)

A -TAG=VALUE string in ExifTool 13.55 travels SetNewValue → ConvInv (Writer.pl:2963) → the
table's CHECK_PROC, which for EXIF/TIFF is CheckValue (Writer.pl:6842-6907). The accepted
shapes are the predicates at ExifTool.pm:5924-5933:

sub IsFloat($) {
    return 1 if $_[0] =~ /^[+-]?(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?$/;
    return 0 unless $_[0] =~ /^[+-]?(?=\d|,\d)\d*(,\d*)?([Ee]([+-]?\d+))?$/;
    $_[0] =~ tr/,/./;   # but translate ',' to '.'
    return 1;
}
sub IsInt($)      { return scalar($_[0] =~ /^[+-]?\d+$/); }
sub IsHex($)      { return scalar($_[0] =~ /^(0x)?[0-9a-f]{1,8}$/i); }
sub IsRational($) { return scalar($_[0] =~ m{^[-+]?\d+/\d+$}); }

Declared type	Accepted	ExifTool source
Integer	123, +123; 0x7b and bare 7b (IsHex); 122.6 rounded half-away-from-zero	Writer.pl:6873-6883
Rational	1/250; 0.004, 5.6, +5.6, 1e1, 5,6; inf; undef	Writer.pl:6888-6900, 5203-5205
Float	5.6, +5.6, 1e1, 5,6 — no fraction form	Writer.pl:6888-6900
DateTime	2024:01:15 10:30:00, 2024-01-15T10:30:00, 20240115103000, 2024:01:15 10:30, trailing Z / +05:00 / .25, now	Writer.pl:5012-5151
String	anything (CheckValue's string/undef branch imposes no shape)	Writer.pl:6847-6858
Binary	the argument's literal bytes	Writer.pl:6847-6858

Key lines quoted in the module doc comment:

# Writer.pl:6875-6883 (integer)
unless (IsInt($val)) {
    if (IsHex($val)) { $val = $$valPtr = hex($val); }
    else {
        return 'Not an integer' unless IsFloat($val) and $count == 1;
        $val = $$valPtr = int($val + ($val < 0 ? -0.5 : 0.5));
    }
}
# Writer.pl:6890-6899 (rational/float/double)
unless (IsFloat($val)) {
    if ($format =~ /^rational/) {
        next if $val eq 'inf' or $val eq 'undef';
        if ($val =~ m{^([-+]?\d+)/(\d+)$}) { ... }
    }
    return 'Not a floating point number';
}
# Writer.pl:5203-5205 (Rationalize)
return (1, 0) if $val eq 'inf';
return (0, 0) if $val eq 'undef';
return ($1,$2) if $val =~ m{^([-+]?\d+)/(\d+)$}; # accept fractional values
# Writer.pl:5149 (InverseDateTime)
$rtnVal or warn "Invalid date/time (use YYYY:mm:dd HH:MM:SS[.ss][+/-HH:MM|Z])\n";

Rationalize's continued-fraction algorithm (Writer.pl:5182-5228) is ported, so oxidex produces
ExifTool's exact denominators: 5.6 → 28/5, 0.004 → 1/250, -0.5 → -1/2.

On an unparseable value

The write is refused, the file is left byte-identical, and the exit status is non-zero. There is no
fall back to String — that is the same bug with a friendlier face, and it is what ExifTool does
too (Warning: Not an integer for ... / Nothing to do.). Error wording follows ExifTool's:
Not an integer, Not a floating point number, Month '13' out of range 1..12,
Invalid date/time (use YYYY:mm:dd HH:MM:SS[.ss][+/-HH:MM|Z]).

Verification — ExifTool read-back on copies

Every write below was applied to a copy; the value was then read with
exiftool -a -G1 -s [-n], not with oxidex's own reader.

JPEG (Canon EOS-1D X, corpus copy):

Command	main	this branch
-ExifIFD:ISO=800	✗ type mismatch	ExifTool: 800
-ExifIFD:FNumber=5.6	✗ type mismatch	ExifTool: 5.6
-ExifIFD:FNumber=1/250	✗ type mismatch	ExifTool -n: 0.004
-ExifIFD:ExposureTime=1/250	✗ type mismatch	ExifTool: 1/250
-ExifIFD:ExposureTime=0.004	✗ type mismatch	ExifTool: 1/250
-IFD0:XResolution=300	✗ type mismatch	ExifTool: 300
-ExifIFD:DateTimeOriginal=2024-01-15T10:30:00	✗ type mismatch	ExifTool: 2024:01:15 10:30:00
-IFD0:Artist=Ada Lovelace	✓	✓ (unchanged)
-IFD0:Orientation=6	✗ type mismatch	ExifTool: Rotate 90 CW (-n: 6)

Non-JPEG — one Integer / Rational / DateTime / String each, all read back with ExifTool:
NEF, DNG, CR2, IIQ, RW2 (corpus copies) and tests/fixtures/tiff/complex/big_endian_001.tif
(that fixture carries no ExifIFD, so it proves Integer + Rational + String; NEF and DNG prove
DateTime as well).

Nothing else moved. Full exiftool -a -G1 -s -n dumps before/after:

• JPEG, -ExifIFD:ISO=800: 382 tags before, 382 after; only ISO, the derived
  Composite:LightValue and IFD1:ThumbnailOffset differ. Thumbnail bytes and the MakerNote block
  are byte-identical (cmp clean) — the offset moves because the surgical writer repacks the EXIF
  segment, which it already did on main.
• NEF, -ExifIFD:FNumber=5.6: 254 tags before, 254 after; only FNumber and the derived
  Composite:Aperture / Composite:LightValue differ.

Corpus integrity. /tmp/oxidex-exiftool-cache/combined-samples/ was never written to. All 4240
files hashed at session start and again at the end: identical. Cross-checked against the source
tarballs (samples-*.tar.gz extracted fresh): 4044/4044 matched, 0 mismatched, before and after.

Tests

• 16 unit tests in src/cli/value_parser.rs — each shape predicate against its ExifTool regex, the
  Rationalize port against known ExifTool outputs, and every accept/reject case verified against
  the real exiftool binary first.
• 18 integration tests in tests/integration/cli_typed_value_tests.rs driving the real binary
  over repo-fixture copies: one tag of each type on JPEG and TIFF; the TIFF cases additionally
  assert the serialized field type (RATIONAL vs ASCII vs SHORT) via scan_exif_entries,
  so a string "300" cannot masquerade as the rational 300/1; batch mode; and unparseable values
  failing loudly with the file left byte-identical.

Gates: cargo fmt --all clean, cargo clippy --workspace clean, cargo test --workspace green
(3316 lib + 522 integration, 0 failures).

Types still not fully settable, and why

• Struct — refused explicitly; there is no command-line syntax for a nested structure and
  exif_surgical::tag_value_to_field rejects TagValue::Struct anyway.
• EXIF:ModifyDate / EXIF:CreateDate — the registry declares these String (not
  DateTime), so a value like 2024-01-15T10:30:00 is stored verbatim instead of being normalized
  to ExifTool's 2024:01:15 10:30:00. Registry data gap, not a parser gap; the space-separated form
  is normalized anyway because cli::args::parse_date_shift claims it first. Filed separately.
• Alias tag keys — -ExifIFD:ExposureBiasValue=-0.5 (EXIF 0x9204, which the reader surfaces as
  ExposureCompensation) now reaches the writer correctly typed, but plan_exif_write's
  duplicate-tag-id guard drops it silently while the CLI still reports success. Pre-existing writer
  behaviour that was previously masked by the type error this PR removes. Filed separately; not
  fixed here because loosening that guard risks the write regressions fix(write): land the non-JPEG write path (issue #20) #358 closed.
• XMP-only tags (e.g. the Float-typed XMP:Exposure2012) parse correctly but the JPEG writer
  does not write XMP — a pre-existing writer gap, unchanged by this PR.

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