v0.12.1 fix i64 hash precision loss across MCP JSON layer

Every FNV1a 64-bit hash above 2^53 (~9e15) silently rounds to the nearest
f64 when JSON's number type passes through the LLM/MCP client layer, making
the entry unrecoverable from the caller's perspective. Hit live during
dogfooding: stored hash 4899385748250478351 became 4899385748250479000 on
recall — found:false even though the body was on disk.

This affected MOST hashes, since FNV1a 64-bit outputs are roughly uniform
across i64 space, so the vast majority exceed 2^53.

Fix: every recall tool now accepts `content_hash_str` (decimal string,
lossless) as an alternative to `content_hash` (integer, lossy above 2^53);
every response includes BOTH forms. The string is preferred.

Tools updated (both input and response):
  - omc_memory_recall / _recall_summary / _recall_codec / _recall_manifest
    — accept content_hash OR content_hash_str
  - omc_memory_store_delta — accepts base_hash OR base_hash_str
  - omc_memory_create_manifest — accepts entries OR entries_str
  - omc_memory_store / _list / all responses — emit content_hash_str
    alongside content_hash for every hash field

Schemas updated to document the precision rule. Helper functions
read_hash_arg() and hash_fields() centralize the dual-form handling so
future tools inherit the convention.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: RandomCoder-lab