Preserve and enforce inline CHECK constraints #562

Inline CHECK constraints are not handled consistently. ALTER TABLE ADD can silently omit a check, allowing values that MySQL rejects. CREATE TABLE also loses inline constraint names, additional checks on the same column, or checks combined with UNIQUE.

Reproduction

CREATE TABLE t (id INT);
ALTER TABLE t ADD a INT CHECK (a > 0);
INSERT INTO t (a) VALUES (0);

Expected: The insert fails because it violates the check, as in MySQL 8.4.

Actual: The insert succeeds. The same gap affects ADD (a INT CHECK (a > 0)).

Additional cases, each on a fresh table:

• CREATE TABLE t (a INT CONSTRAINT positive CHECK (a > 0)) enforces the check but replaces its explicit name with t_chk_1.
• CREATE TABLE t (a INT CHECK (a > 0) CHECK (a < 10)) enforces only the first check and accepts a = 11.
• CREATE TABLE t (a INT UNIQUE CHECK (a > 0)) enforces uniqueness but accepts a = -1.

These differences were reproduced against MySQL 8.4.

Required behavior

• Preserve and enforce every inline check in CREATE TABLE, single-column ADD, and parenthesized ADD lists.
• Preserve explicit constraint names and generate distinct names for unnamed checks.
• Handle checks alongside other column constraints without dropping either constraint.
• Cover enforcement, information-schema metadata, SHOW CREATE TABLE, and rollback when existing rows violate a newly added check.

The shared record_add_column() path does not write the check expression to CHECK_CONSTRAINTS. The existing extraction helpers also select only the first check or one constraint type per column, so copying the current CREATE TABLE handling alone does not cover all cases.

Found while reviewing #557. These behaviors predate that PR and are separate from its parenthesized-list fix.

Related: #162.