feat: validate the distance type in the model header (closes #23)

[Dani-giron]

Summary

dump()/load() validated M, M0, EF and HEURISTIC but not the distance type. A model built with one distance loaded silently into a type using another: bincode does not depend on D (distance structs are zero-sized, no trace in the serialized body), so the graph deserialized fine and every later search computed distances with the wrong function, with no error. Verified empirically: with the check disabled, loading a NormalDistance model into an InvertedDistance type returns Ok with the full graph recovered.

Changes

• src/datalayer/algorithms.rs: DistanceAlgorithm gains a stable const TYPE_NAME: &'static str, declared by both implementations (NormalDistance, TlshDistance).
• src/controllers/apotheosis.rs: dump() writes an FNV-1a hash of D::TYPE_NAME as 4 extra header bytes (17 -> 21). load() recomputes it for the loading type and rejects a mismatch with a descriptive error. FNV-1a instead of type_name()/std hashers because it is fully specified and stable across Rust versions, which a persistence format needs.
• tests/header_distance.rs (new): mismatch is rejected, matching distance loads fine.

Record type R is not validated here, intentionally out of scope (see issue #23): R types usually have non-zero-sized fields, so a mismatch there is more likely to surface through bincode on its own.

Test plan

• cargo test --test header_distance: 2/2 pass.
• Manually reproduced the pre-fix bug by temporarily disabling the check: load() returned Ok with the graph fully populated under a mismatched distance, confirming the silent-acceptance behavior before writing the fix.
• cargo clippy/cargo fmt on the full crate could not be verified locally (unrelated toolchain issue on this machine, disk near full); the two changed files were checked individually with rustfmt --check and pass. Will be validated by CI on this PR.

Closes #23