fix: clarify memory selection semantics

harness/.pi/skills/tht-sessione/memoria.md

@@ -24,14 +24,13 @@ Rules:
   (e.g. `question_rewritten`, `sql_approved`) are NOT to be proposed: they don't
   transfer to other questions.
 - All candidate memories go in **a single** `reviewer_decide(multi:true,
-  advance:true, allow_empty:true)`: each selected option is applied (register the
-  decision with the appropriate type, citing the memory id in the rationale), each
-  deselected option is **recorded as `memory_rejected` by the gate** (so the next
-  `tht memory search --session` won't re-propose it). To enable this, EVERY memory
-  option MUST carry the field `mem_id:"mem-<id>"` (besides `type`/`subject`/
-  `rationale`). The checklist starts pre-selected with the recommended memories.
-  With `allow_empty:true` an **empty selection is accepted** (no memory applied; the
-  deselected ones are still recorded as rejected) and the phase advances — no
+  advance:true, allow_empty:true)`: every option describes a candidate memory, never
+  an opposite action such as "do not use it". Each selected option is applied
+  (register the decision with the appropriate type, citing the memory id in the
+  rationale). Mark `recommended:true` ONLY on memories proposed for use: those, and
+  only those, start checked. An unchecked memory is **not applied now**; it is not a
+  rejection and may be considered again if Phase 2 is reopened. With `allow_empty:true`
+  an **empty selection is accepted** (no memory applied) and the phase advances — no
   separate gate.
 - For "inspect": show the memory's full JSON record in the prose before presenting
   the checklist, if the reviewer asks.