Fix inline PRIMARY KEY and UNIQUE parsing and metadata #563

Inline key declarations have two related problems: UNIQUE KEY can be mistaken for a primary key, and keys added with ALTER TABLE ADD have incomplete or incorrect metadata.

UNIQUE KEY is treated as PRIMARY KEY

CREATE TABLE t (id INT PRIMARY KEY, a INT UNIQUE KEY);

Expected: Create a primary key on id and a nullable unique key on a, as in MySQL 8.4.

Actual: Creation fails with a duplicate-entry error in the driver's INFORMATION_SCHEMA.STATISTICS storage because both keys are recorded as PRIMARY.

The same failure occurs with:

CREATE TABLE t (id INT PRIMARY KEY);
ALTER TABLE t ADD a INT UNIQUE KEY;

Plain UNIQUE does not have this parsing problem.

ALTER TABLE ADD omits key metadata

Run separately on a fresh table:

CREATE TABLE t (id INT);
ALTER TABLE t ADD a INT PRIMARY KEY;

SELECT CONSTRAINT_NAME, COLUMN_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 't';

SELECT INDEX_NAME, NULLABLE
FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 't';

Expected: KEY_COLUMN_USAGE contains PRIMARY, a, and STATISTICS.NULLABLE is an empty string.

Actual: KEY_COLUMN_USAGE is empty, and the primary-key index reports NULLABLE = 'YES', even though the key is enforced.

Added inline UNIQUE keys also lack KEY_COLUMN_USAGE rows. NOT NULL UNIQUE additionally reports the wrong index nullability. Parenthesized ADD lists share these metadata gaps.

Required behavior

• Distinguish UNIQUE KEY from PRIMARY KEY in both CREATE TABLE and ALTER TABLE.
• Record complete key metadata for inline primary and unique keys added by either ADD form.
• Derive index nullability from the column definition.
• Cover key enforcement, nullable unique keys, information-schema metadata, and SHOW CREATE TABLE.

The declaration helpers currently interpret the KEY token in UNIQUE KEY as a primary key. Separately, record_add_column() omits key-column usage and passes a fixed nullable value when building index metadata. Both failures were reproduced against MySQL 8.4.

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

Related: #162.