fix(mcp): smem_edit refreshes content_hash and the embedding on a content change

[RobertSigmundsson]

Summary

• A content edit through smem_edit now recomputes content_hash and, when the neuron already carries an embedding, re-embeds the new text through the same provider path the write path uses.
• If the provider is unavailable, the edit still succeeds but logs a warning naming smem reindex --all — the stale vector becomes loud and repairable instead of silent and invisible.
• Adds three regression tests: hash refresh, vector refresh, and the provider-unavailable fallback.

Why

Both edit paths did dc_replace(neuron, content=new_content) and handed the result to update_neuron. That writes content_hash from the object and the vector from metadata["_embedding"] — and since _row_to_neuron surfaces the stored vector into that key on read, the old embedding was not merely left behind. It was actively re-saved against the new text, on every content edit.

Three things drift at once, and each is quiet in its own way:

• Semantic recall returns the memory for what it used to say. The worst case we measured is also the most natural use of an edit: an entry corrected specifically to say it is outdated was still retrieved as if current, because its vector still described the pre-edit text.
• reindex --missing-only (the default) cannot see the damage. The vector field is never empty, so the only repair is a blind --all re-embed of the whole brain.
• Near-duplicate detection compares fingerprints of text that no longer exists, since content_hash is a stored field, not a computed one.

Measured on a production brain of ~15k neurons (full re-embed and cosine compare of every neuron): 7 edited memories had drifted, worst cosine 0.75 against a flat 1.0000 for every untouched neuron — and all 7 carried an explicit correction marker in their text, i.e. they were exactly the memories someone had cared enough to fix.

Design choices, called out so they are decisions rather than surprises:

• The embedding is refreshed only when one already exists. Installs without an embedding provider have no vector to go stale, and the edit path gains no new dependency on one.
• On provider failure the edit keeps the old vector and warns, mirroring the write path's fail-soft philosophy (a slow or absent provider must not turn a successful edit into an error). If you would rather clear the vector so --missing-only picks it up, that is a one-line change in the helper — I chose the warning because clearing silently degrades recall for that memory, and the log line names the repair either way.
• The same stale-derived-data pattern exists in mcp/instruction_handler.py and in engine/compression.py's compress/restore paths; this PR deliberately fixes only the user-facing edit tool. Happy to follow up on the others if you want them handled the same way — and a reindex --stale mode (re-embed-and-compare, which is how we found this) might be worth having regardless.
• metadata["_structure"] has the same problem on content edits. I have left it out of this PR and will raise it separately, because it needs a product decision (recompute vs drop) rather than a mechanical refresh.

Test plan

• pytest tests/ -m "not stress" -n auto passes locally — 7020 passed, 142 skipped, 1 xfailed (baseline on main is 7017; the delta is this PR's three tests).
• ruff check src/ tests/ clean; ruff format --check clean.
• mypy src/ --ignore-missing-imports clean — no issues in 353 source files.
• All three new tests were proven to fail on main's lifecycle_handler.py: the saved neuron kept the old content_hash, kept the old vector, and no warning was emitted — the exact silent behaviour this PR removes.
• Diff touches mcp/ and tests/ only; no server routes or dashboard assets.

Verified by

@RobertSigmundsson

[acidkill]

Verified locally on top of this branch:

• The bug is real and I traced the full chain: _row_to_neuron surfaces the stored embedding_vec into metadata["_embedding"] on read, the old edit path passed it through dc_replace untouched, and update_neuron pops that key straight back into embedding_vec — so every content edit actively re-saved the OLD vector against the NEW text, and reindex --missing-only could never see it. content_hash likewise persisted the object's stale SimHash.
• The fix matches the write path: _create_provider(..., task_type="RETRIEVAL_DOCUMENT") + embed_batch([embedding_text()]) under _inline_embed_timeout() is the same shape encoder uses.
• Fail-soft on provider unavailability is the right call for an edit tool, and the warning names the repair command.
• All three new tests fail on main's handler and pass with the fix (verified by reverting just the src file); full module 15/15; ruff/format clean; mypy only the pre-registered `google.genai] env error; Integration rerun green (earlier fail was the pre-#172 signin flake).

Follow-ups worth their own issues when you get to them (as the PR body already flags): the same stale-derived-data pattern in mcp/instruction_handler.py and engine/compression.py, metadata["_structure"] on content edits, and a reindex --stale mode.