practicas.numeroHistoriaClinica non-blank + trimmed CHECK, and clean the one untrimmed row

Split out of PLUTO-737 on audit-terra-cc's ruling (2026-09-11): NOT NULL answers "is it present", a CHECK answers "is it valid", and mixing them under a one-line-DDL review would have been a silent widen. PLUTO-737 shipped the NOT NULL (migration 120, applied 2026-09-11 14:50 ART, attnotnull=true, 1219 rows, 0 NULL). WHAT IS STILL OPEN: the column now admits ' ' from any write path that skips the three app guards (practica-actions.ts:100 createPractica, :971 updatePractica, :1276 updateNumeroHistoriaClinica, all of which trim today). The structurally complete rule is CHECK ("numeroHistoriaClinica" = btrim("numeroHistoriaClinica") AND "numeroHistoriaClinica" <> ''). LIVE COUNTER-EXAMPLE ALREADY IN THE TABLE, measured 2026-09-11: practicas.id b82660e5-7880-43ee-b067-d5449ffd3b55 holds '86626 ' - length 6, btrim length 5, fecha 2026-08-03, createdAt 2026-08-03T19:24:54Z, deletedAt NULL. An exact-match lookup on '86626' misses that practica today. It is the ONLY such row (census: 1219 rows, 1 untrimmed, 0 blank-after-btrim). It predates the eq#61 guards, so this is legacy residue rather than an open leak. ORDER MATTERS: the CHECK cannot be added as VALID while that row exists, so decide first - (a) UPDATE the one row to btrim it and then add the CHECK as VALID in the same migration, or (b) add the CHECK NOT VALID and defer VALIDATE CONSTRAINT. (a) is one row and one lock and is the recommendation; (b) only makes sense if someone argues the stored value is intentional, which nothing suggests. Note the archive rail: practicasArchive stores jsonb snapshots and has no numeroHistoriaClinica column, so an UPDATE here writes an archive row via the existing trigger but does not need a schema change there. Class-A DDL on a live table: own pre-apply review (audit-terra-cc is the standing stand-in for pluto DB work), re-run the census immediately before applying, SET LOCAL lock_timeout, and verify pg_constraint.convalidated after.