Port Terra's participant-dispute mechanism to Pluto (replaces building a removal kind)

Split out of PLUTO-744 by pmmaster-evolutiva-cc 2026-10-06 so that 744 can close on what was actually done. The single outstanding removal case WAS handled case-by-case and verified: practica 90913dac applied by db-pluto-cc 2026-09-28, asistenteId NULL, one practicasArchive row, reason admin:sop-pluto-16-remove-asistente-no-objection, ticket closed 09:56:59, confirmed by support-evolutiva-cc with a SELECT the same day. The ruling not to build a removal kind needs no implementation. So 744 had nothing executable left and was being held open only to keep a dependency visible - which is what a child row is for. THIS ROW IS THE PORT, and it does not start until Terra's mechanism exists. BLOCKED ON TERRA-146 (dispute state model, now ruled and building) and TERRA-276 (the validation state primitive it needs). WHAT GETS PORTED, as ruled on TERRA-146 - port the semantics, do not redesign them: no unilateral removal of a participant, because participation carries medico-legal weight and erasure lets someone drop a TRUE fact after a bad outcome. A pending dispute keeps the row LIVE (deletedAt NULL) and is excluded from confirmed counts and listings by disputeStatus; only resolution=removed soft-deletes; a rejected dispute leaves the row live, so there is no undelete path. The exclusion must live in ONE canonical view or helper every confirmed count reads through, never N filters in N readers. One open dispute per (practicaId, userId, rol) per disputant. The re-add guard blocks the disputed tuple only; an independent second role may exist, and creating one during a standing dispute writes an event so the bypass is visible rather than refused. WHY A PORT AND NOT A FRESH DESIGN: removal semantics that differ between two apps on the same domain object is the actual risk here, not the missing button. If Pluto's constraints genuinely force a divergence, raise it as a difference to be ruled, do not quietly implement a second shape.