Make logical identity and hydration deduplication namespace-safe

[valiantone]

Context

HotMem currently derives inline content identity from identifier and fact_text, while database and hydration deduplication use content_hash without a namespace dimension. Consequently, equivalent facts belonging to different namespaces can collide, while identity and content-integrity concerns remain coupled.

What needs to be done

• Define the logical identity tuple for inline and file-backed memories, including namespace and normalized source identity where applicable.
• Decide whether content integrity and logical identity must be represented separately.
• Align database uniqueness, exists, bulk insert, Snapshot v2 hydration, bundle import, legacy JSONL hydration, API, MCP, and SDK behavior under one contract.
• Define compatibility and migration behavior for records produced with the current namespace-agnostic hashes and any existing unique index.
• Add adversarial fixtures for identical identifiers/facts in different namespaces, same-scope repeat imports, empty hashes, and file-backed records.

Acceptance criteria

• Two otherwise identical records in distinct namespaces survive storage, export, and hydration as two records.
• Re-importing the same record into the same identity scope is idempotent and reports a skip rather than creating a duplicate.
• Inline and file-backed records follow documented identity rules.
• Existing databases with legacy content hashes have a deterministic, tested compatibility or migration path.
• Every ingestion surface that relies on content_hash is enumerated and either updated or explicitly declared unaffected.
• The contract clearly identifies which values establish logical identity and which values only verify content.

Constraints and non-goals

This issue does not create cross-user federation, entity-resolution services, access-control policy, distributed conflict resolution, or a global identity service. Namespace is a local portable scope, not an enterprise authorization decision.