[Reborn] Centralize snippet display hashing

[serrrfirat]

Summary

• add a shared run-profile helper for opaque model-visible snippet display hashes
• use it for skill snippet model-message refs and memory snippet refs
• remove duplicated FNV-1a hash loops from call sites

Scope

Follow-up to #3476/#3470. Addresses the #3492 comment item: snippet-ref hash derivation should not be duplicated across prompt/context paths.

Verification

• CARGO_TARGET_DIR=/Users/firatsertgoz/Documents/ironclaw/target cargo test -p ironclaw_turns -p ironclaw_host_runtime
• CARGO_TARGET_DIR=/Users/firatsertgoz/Documents/ironclaw/target cargo test -p ironclaw_architecture

Does not close #3492.

[gemini-code-assist]

Code Review

This pull request centralizes the FNV-1a hashing logic for model-visible snippet references into a new snippet_ref module, replacing duplicate implementations in memory_context.rs and skill_context.rs. Feedback indicates that the new centralized helper introduces a subtle change in hash calculation by appending a trailing field separator, which may break backward compatibility for existing or persisted LoopMessageRef strings.

[gemini-code-assist]

The centralization of the hashing logic here introduces a subtle change in the resulting hash value for skill snippets. The previous implementation (stable_snippet_ref_hash) did not include a trailing field separator after the final ordinal field, whereas the new stable_snippet_display_hash appends a separator after every field in the iterator.

While these hashes are documented as opaque display identifiers, this change will break any existing or persisted LoopMessageRef strings that were generated using the old logic. If backward compatibility for transcript resolution or in-flight runs is required, this should be addressed by either adjusting the centralized helper or explicitly handling the trailing separator in the call site.

References

1. Prioritize backward compatibility for existing data and logic when modifying centralized helpers or established formats.

[serrrfirat]

Paranoid review found a Medium issue at head 52d38d2181d6cf45d4d3ccc720ba5dfb966eba7c:

#	Severity	Confidence	Category	File:Line	Finding
1	Medium	Certain	Correctness / compatibility	crates/ironclaw_turns/src/run_profile/skill_context.rs:410	skill_snippet_model_message_ref now hashes [snippet_ref, safe_summary, ordinal] through stable_snippet_display_hash, whose implementation appends 0xFF after every field (snippet_ref.rs:16-21). Old skill refs used separators only between fields (snippet_ref, safe_summary, ordinal) with no trailing separator. Concrete vector: old skill_snippet_model_message_ref("skill:alpha", "summary", 0) hash was 6e54cb74d742607c; new hash is bc763a89c5c9fe99. Any persisted/precomputed LoopModelMessage ref from before this PR will still look like msg:snippet.* but HostManagedModelPort::instruction_snippet_messages_by_ref will recompute only new refs, miss old refs, then fail model resolution with model message reference is unavailable. Memory snippet refs keep old behavior because their previous helper already appended a separator after each field. Fix/test: preserve old skill hash semantics while still centralizing feed logic, e.g. shared private FNV feed plus explicit separator mode (BetweenFields for skill refs, AfterEachField for memory refs), or otherwise version/migrate snippet refs intentionally. Add exact compatibility tests for both skill_snippet_model_message_ref("skill:alpha", "summary", 0) and a memory-path hash vector so future centralization cannot silently change either protocol.