wi rename is last-writer-wins AND does not log the old title: removing a dangerous instruction from an item destroys the evidence of it

Two defects in the wi CLI's rename path, both found 2026-09-12 during the OPS-53 close, both measured rather than inferred. CONTEXT that makes them matter: OPS-53 was closed with a resolution OPPOSITE to its own title, and wi-cli's completion announce fans out the TITLE rather than the closing body - so the fleet received the rejected approach stamped 'done'. The remedy is to rename an item before closing it against its title. Both defects are in that remedy. (1) RENAME IS LAST-WRITER-WINS WITH NO CONFLICT SIGNAL. pmmaster-evolutiva-cc and bin-whey-cc were both alerted by monitor-context-cc's broadcast and both rewrote the stale title independently, 8 seconds apart (00:14:36.732 and 00:14:44.990). The second write silently discarded the first. No divergence in substance this time, so only wording was lost - but the mechanism is general: a broadcast alarm about a stale artifact reliably draws two lanes onto the same one-line fix and one of them loses without being told. Same shape as a newest-wins merge hazard, in the tracker instead of in git. (2) RENAME DOES NOT LOG THE OLD TITLE - AND describe DOES LOG THE OLD TEXT, so the asymmetry is inside one CLI. 'wi describe' logs descriptionChanged carrying the old body; 'wi rename' logs titleChanged carrying the NEW title only. Consequence: after the first rename the original 2026-05-21 filing text existed nowhere in the item, and after the second, neither did the first rename's wording. RENAMING AN ITEM TO REMOVE A DANGEROUS INSTRUCTION CURRENTLY DESTROYS THE EVIDENCE OF WHAT IT USED TO SAY, which is precisely the case where the audit trail is wanted. OPS-53's original title was recovered only because bin-whey-cc happened to take a 'wi show' before either rename. FIX: titleChanged should carry the old title (match describe's contract), and rename should refuse or warn on a title that changed since the caller last read it. OWNERSHIP IS THE BLOCKER, NOT THE CODE: the basquetWi lane is shut down (coder-basquetwi-cc unregistered), wi is a launcher that execs a per-host basquetWi checkout, and who may change that surface is one of Elazar's open decisions. This item is the third thing stacked behind that decision, after the three inert migrations and the impact field.