fix(build): rebuild C outputs on HUF mode changes

Mode-specific Rust archives exposed the test makefiles' flat C-object cache:
switching from default to forced HUF mode could relink stale default C objects
with a newly built forced Rust archive. That hybrid has incompatible decoder
table expectations and can corrupt dictionary decompression.

Track each makefile's effective HUF mode with an empty archive stamp. It is a
safe normal linker prerequisite, and every mode transition advances its mtime
so cached C objects and direct-source binaries rebuild while unchanged modes
remain incremental.

Test Plan:
- cargo clippy; cargo clippy --benches; cargo clippy --tests
- cargo +nightly fmt, then repeat the Clippy checks
- cargo test --all-targets
- Default -> forced-X1 -> default fuzzer builds without -B, each running
  ./fuzzer -s5346 -i1 --no-big-tests
- Equivalent zstd-small default/forced/default rebuild and --version checks

Refs: rust/README.md
Fixes: d89ebb31

rust/README.md

@@ -45,9 +45,9 @@ preprocessor behavior stay available during the transition.
 
 The test and program makefiles select an archive directory for the active C
 configuration: default, forced HUF X1/X2, and the matching Rust target for
-32-bit C binaries. They rebuild the selected archive and relink the executable
-when a Rust source changes, so original C tests do not accidentally use a
-stale or configuration-incompatible implementation.
+32-bit C binaries. When the HUF mode changes, they also rebuild cached C
+outputs before linking. This prevents original C tests from using a stale or
+configuration-incompatible implementation.
 
 ## Validation