fix(tag-comparison): stop writing the disk tag-cache inside the sample corpus

[swackhamer]

Summary

• Both extractors (OxiDexExtractor, ExifToolExtractor) derived their on-disk tag-cache directory from fixture_path.parent(). That resolves to the sample corpus itself whenever fixture_path points at a vendor subdirectory (e.g. combined-samples/Olympus), and it corrupted the read-only corpus in place on 2026-08-01.
• Added a shared extraction::cache_dir::resolve_cache_dir() helper that never inspects fixture_path's parent. Priority: --tag-cache-dir CLI flag → OXIDEX_TAG_CACHE_DIR env var → a temp-dir location keyed by an MD5 hash of the canonicalized fixture path.
• Wired both extractors through the shared helper via a with_cache_dir_override builder, fixed the stale comment referencing the old /tmp/oxidex-exiftool-cache/oxidex-tag-cache/gif.json path, and added the flag to main.rs.

Test plan

• New regression test mutation-tested against the original buggy .parent()-walk logic (confirmed it fails for the right reason), then verified green against the fix.
• Regression test added to both oxidex_extractor.rs and exiftool_extractor.rs, each asserting the cache dir never lands under an observable fixture parent.
• cargo test --bin tag-comparison --features tag-comparison-binary — 71/71 passed
• cargo clippy --bin tag-comparison --features tag-comparison-binary -- -D warnings — clean
• cargo fmt --all
• Verified /tmp/oxidex-exiftool-cache/combined-samples is still exactly 4238 files with no *tag-cache* entries after the test run

🤖 Generated with Claude Code