[bug] Behaviour self-heal can delete a user-set memory entry, contradicting the never-delete-user-set rule

[serge-ivo]

Regression introduced by #226.

What happens

agent-think.ts builds a self-heal block listing memory keys that hold communication
preferences and tells the agent:

"…move each one with set_behaviour and then delete_memory the old key."

Two lines earlier, the same prompt says:

"Entries marked (user-set) were set directly by the user — never overwrite or delete them
unless the user explicitly asks."

The stray list does not exclude source: "user" entries, and it is the more specific,
later instruction — naming exact keys and an exact tool. A model will follow it.

The Memory tab is editable and tags manual entries source: "user", so this is reachable: type
preference:tone into Memory by hand, then ask the agent anything about how it communicates,
and it deletes your entry. Memory deletion has no undo.

Confirmed reachable, not theoretical — the agent already performed exactly this delete on a live
instance (delete_memory preference:response_style); it happened to be an agent-written entry
that time.

Fix

Filter source === "user" out of the strays list. For those, the agent should offer to move the
preference and leave the entry alone unless told otherwise — which is what the general rule
already says.

Verification

• A user-set stray is listed for MIGRATION but never for deletion, asserted on the built prompt.
• An agent-written stray still gets the move-and-delete instruction (the migration must keep
  working).

[serge-ivo]

Shipped in 52ca508 — closing, left open by the delivering agent.

behaviourStrayPrompt (pure, exported) replaces the inline block: agent-written strays still get move-and-delete, user-set strays are listed for the move only, with an explicit "never delete_memory a user-set key — offer, and only remove it if they say yes". A test guards that no user-set key ever appears on a line containing the delete instruction.

Correction to the stated impact: "memory deletion has no undo… it deletes your entry" is not what happened. lib/tools.ts:227 already hard-blocks it — delete_memory on a source:"user" entry returns success:false with "only the user can remove it", and write_memory has the same guard. No user memory was ever lost, which is consistent with this ticket's own evidence: the one live delete cited succeeded precisely because it was agent-written.

The real cost was a prompt instructing a tool call the platform had already decided to reject — a wasted round, a failure the model then has to explain, and the invariant contradicted eleven lines after being promised, in the place a model reads most literally.