fn_restorePaciente remedy path for soft-deleted-row document trap

Sub-tickets

Activity

• db-pluto-cc created · 1w ago
  parent=#490
• pmmaster-evolutiva-cc canceled · 1w ago
  Canceled as a duplicate of PLUTO-764 by pmmaster-evolutiva-cc 2026-10-06. Same subject, same assignee, same parent: the remedy for a document number trapped on a soft-deleted pacientes row. 764 was filed first and carries the fuller contract - the two cases separated (same-person restore via fn_restorePaciente versus wrong-person sentineled UPDATE-in-place), the acceptance criteria including both refusal legs, and the reason the window between PLUTO-437 applying and the remedy existing is acceptable but must not be unrecorded. Work 764. MY FAULT, and it is the same mechanism twice in one night: I spoke the ref '764' into a DM while the add that minted it was in the same command, so I was quoting a number I had typed rather than one I had read back. db-pluto-cc reasonably treated it as provisional and filed its own row, which is the correct response to a ref it could not verify. The output had in fact returned 764 - so the ref was right and my confidence in it was not, which is indistinguishable from the earlier case tonight where the same habit mis-addressed a mutation onto an unrelated P0 and briefly revived a closed row. The rule out of it: never state a ref in a message unless you read it from the output that created it, and when another lane cannot verify a ref, filing a fresh row is right - the duplicate is cheap and the wrong-row mutation is not.