A check constraint the schema cannot name can never be retired, and keeps enforcing the old rule #107

Summary

A column-level checkConstraint has no name field, so the migrator can only ever rewrite the constraint it created itself (<table>_<column>_chk). A check constraint that predates DataProvider, or was added by hand, can never be retired — and it keeps enforcing the old rule after the schema changes it.

Found by TradiSite on a production-shaped postgres:17 with 0.9.12-beta.

Reproduction

1. Migrate a schema with a column checkConstraint on usage_tracking.event_type. DataProvider creates usage_tracking_event_type_chk.
2. Simulate a legacy duplicate, as TradiSite production has:

   ALTER TABLE public.usage_tracking
     ADD CONSTRAINT usage_tracking_event_type_check CHECK (event_type IN (...));

3. Change the allowed values in the YAML and migrate again. DataProvider rewrites _chk and leaves _check in place.
4. Insert a row using a newly allowed value:

   ERROR: new row for relation "usage_tracking" violates check constraint "usage_tracking_event_type_check"
   

Why it matters

The migration reports success, the schema says the value is allowed, and the database rejects it. For an asynchronous writer that is silent data loss: the row is dropped and nothing surfaces it. TradiSite had to freeze event_type at exactly what production already enforces (their PR #140) rather than migrate at all.

Fix wanted

Either let a column checkConstraint carry an explicit name, or let the schema declare legacy constraint names to drop. Either lets pre-DataProvider constraints be retired through the sanctioned tool instead of by hand.

Related: #105. Reproduction write-up: docs/reports/dataprovider-migrate-defects.md in the TradiSite repository.